Re: AMD planning 45nm 12-Core 'Istanbul' Processor ?

On May 28, 10:23 am, Sebastian Kaliszewski
<s.usun...@xxxxxxxxxxxxxxxxxxx> wrote:
Robert Myers wrote:
And that's the fact. Otherwise they would be nonexistent.

They're merging and going out of business at an amazing rate.

Another attempt at twist?

Are they alive? Or not?

The
only reason they're still afloat is because the US Treasury and
Federal Reserve have done things they couldn't or wouldn't do in 1929.

Uh, oh.

What does that mean?

Don't speak about things you know little about.

Others have answered your nonsense already.

The more you say things like that, the less credible you become.


Then add to that that its your
central bank and your government which worked hard not so long ago to make
the situation as it is now (for short term gains). They have screwed so
they have to intervene now.

I don't claim to understand what's happening outside the US, except
that the debt crisis is worldwide. Jerome Kerviel was working for a
French institution. As far as I could tell, he was playing the same
fool's game: trying to make big money by assuming arbitrarily large
risk. We live in worldwide markets. "They" is increasingly "us."

When I pointed out the obvious, he changed
his assertion.

Nope. Your idiotic apples to oranges comparison doesn't change my
assertion at all.

You said they know how to estimate risk. Very, very famously, they do
not.

Guy can't fly a plane so he can't drive a car -- it's the same idiotic
logic.

So. What you *should* have said was, "Financial institutions can't
estimate risk in their main line of business, but they know all about
software."

You're piece of the work. They *can* & *do* estimate risk in their main line
of business. Otherwise they would be dead long time ago.

Well, no. They've discovered an elaborate scheme for transferring
risk around, taking a profit as it changes hands.

Heard of Bear, Stearns? Once one of the most feared and ruthless
investment banks on Wall Street:

http://online.wsj.com/article/SB121193290927324603.html (subscription,
but since you know so much about the business, I'm sure you have one).

Here's a New York Times link:

http://dealbook.blogs.nytimes.com/2008/05/28/for-bear-fear-in-the-market-was-fatal/?hp

You have to register, but it's free.


My first example was
of a failure of software used to estimate risk, not of the risk to the
software itself.

Which is completely off side.

You made broad claims about risk estimation. I've made broad counter-
claims. Neither NASA nor Wall Street knows as much as it thinks it
does. There are all kinds of problems. So your sweeping claim that
everything is okay because you work for people who know how to
estimate risk is laughable for a number of reasons:

1. The methodology of risk estimation is not in good shape.
Historically, people have made claims that haven't been supported by
experience.

2. In particular, people who have "critical" applications have made
big screwups: NASA and investment bankers--and Arianspace.

3. In particular, the kinds of people you claim for credibility are
not credible. You'll search the pages of the Wall Street Journal for
a long time without finding such an admission because the claimed
credibility is the source of so many paychecks, including yours.
Because lots of people are doing something a particular way doesn't
make it right.

4. Actual and very serious problems have occurred.

I very well knew that.

So you intentionally tried to twist..

There was no intent to deceive you.

You keep calling me derogatory names, but maybe you want to step back,
calm down, and listen.

The big, underlying event here is computers. Microprocessors were a
game changer, but not as big as computers themselves. Computers made
possible calculations that were previously unthinkable. They
introduced the possibility of strategies so complicated that no
ordinary mortal could understand them or keep up with them (e.g.
program trading).

The ability to do those calculations and to implement those strategies
has introduced a new kind of risk, which is, ironically, the risk that
your method of estimating risk is faulty. Engineers have always
understood that elimination of risk is impossible and that estimation
of risk often just guesswork. What's different about financial
markets is that people are becoming more aggressive with risk because
computers give them the illusion that they understand it better than
they do.

*That's* why I have talked not only about the process at risk (writing
software), but about the software used to estimate risk. Probably it
would have been less confusing if I had talked about the methodology
used to estimate risk, but the fact that it's often being done by
computers is telling: we're removing ourselves ever further from the
actual problem.


The software that NASA used to assess risk
got wildly optimistic answers.

Whatever. What all of that has to software production methodology?

Risk estimation is risk estimation. Or are you telling me that
financial software has invented its own methods for estimating risk?
That's reassuring.

That says there is something wrong
with the methodology to assess risk.

Risk of what?

So, let's see. There's a theory of risk for each human activity?
There's something special about software development that makes it
more analyzable than other human activities?


I've also given examples of
failures of the software itself (flight control software for deep
space probes) and Standard and Poors giving AAA rating to securities
that probably should have had junk bond status. That's *three*
different kinds of software. I hope you can keep them straight.
You are swimming against the tide.

LOL!

The huge pile of software that's out there was, largely, built to
exploit the capacities of one-processor systems. One-processor
systems are going the way of the dinosaur.

Individual cores of multicore machines are not slower than earlier single
cores. They are much faster in fact. The huge pile of software out there
is "happy" with fraction of performance of that single core. So the soft
utilises less than 25% of power of that Core2 Quadro? Who cares.

Plenty of people will care. It's the same as the time-to-market
argument. If your competitor can do it better or faster, you're
screwed.

The problems with multi-
processor programming are fundamental and make the problem of software
bugs much, much worse. Something has to give.

Whatever. It so happens that software I typically work on is designed to
work in thousands concurrent contexts. 100 core machines? Nice, our clients
will be able to reduce hardware costs and run our software on few machines
instead of few hundreds.

Yes, classical multithreaded programming is most likely to give. It scales
poorly and introduces tons of heisenbugs. But there are already known ways
to deal with that. Those who made only single-context programs will have to
learn new things -- but it was allways that way in software development --
you learn new things all the time or you're off.

Only time will tell. You see a gradually changing landscape. I see
an earthquake.



The energy that you've put into
this discussion is nothing short of amazing. "Current methods of
writing and maintaining software are adequate" is a fascinating
claim. You must live on another planet.

ROTFL!

You're simply piece of the work. Go on! Keep invenitng what others have
said.

Current methods do work. It doesn't change the fact that these methods do
evolve. But they evolve to make software production more effective not to
satisfy some guy with high school kid attitude and black-white views.

No one has to satisfy me about anything. As to the methods of
software production evolving, that's laughable.

It's laughable only for the clueless.

There is no way that I can see for currently existing software methods
to "evolve." They're built around languages that have no built-in
semantics for concurrency.

What we see are heaps
and heaps of tools and languages, none of them fundamentally better
than what's been in place for decades.

Fundamentally is not required. Simply better is enough. Black-whites with
lack of grip in reality are not satisfied -- but reality does not care.

I'm not convinced that many of the tools are even better. Simply
labeling thinking as black and white is lazy. Yes, I have a
mathematician's view of some things. In fact, I take a
mathematician's point of view whenever I can. In mathematics, things
are usually either right or wrong, although, ironically, mathematics
has started to have the same class of problems. I'm not sure why
"gray" thinking is being advanced as the appropriate mindset for
working with computers. If you're so stuck in your mindset that you
can't understand what I'm saying, you can't compensate by calling me
names and applying labels.

I just don't know what to say
to someone who says, "Current methods do work." Manifestly, they
don't.

ROTFL!!!

So how you managed to even post that nonsense to this newsgroup. If the
metods to produce software to post didn't work there should be no
software...

"It works most of the time" is not an acceptable standard of quality.

Robert.
.

Relevant Pages

  • Re: AMD planning 45nm 12-Core Istanbul Processor ?
    ... similar to a risk taken by a thief. ... estimate risk in their main line of business, ... of a failure of software used to estimate risk, not of the risk to the ... The methodology of risk estimation is not in good shape. ...
    (comp.sys.ibm.pc.hardware.chips)
  • Re: AMD planning 45nm 12-Core Istanbul Processor ?
    ... similar to a risk taken by a thief. ... The nature of the business is that it is no different from sports ... but not as big as computers themselves. ... but about the software used to estimate risk. ...
    (comp.sys.ibm.pc.hardware.chips)
  • Re: AMD planning 45nm 12-Core Istanbul Processor ?
    ... We all die one day, and there are lots of risks before then. ... For many people untested drugs are the only chance. ... know how to estimate risk. ... You said they know how to estimate risk. ...
    (comp.sys.ibm.pc.hardware.chips)
  • Re: So lets build a router
    ... within the control of the project team. ... No matter what methodology used some projects will not ... This is why a risk mitigation plan: ... > could model different concepts of success/failure which put emphasis on ...
    (comp.object)
  • Re: Network Hacking
    ... respect the rights of others, or else you risk getting your rights taken ... You don't have to hack into live computers to learn how to secure ...
    (microsoft.public.win2000.security)