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

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. 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.


>> >> > 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.


>> >> > Yes, indeed, just as I said, Wall Street is a kind of
>> >> > Ponzi scheme, and the game right now is who gets stuck with the
bad
>> >> > paper.
>>
>> >> Whatever. These guys make money wether there is upturn or downturn.
>> >> One may like it or not, but their attitude "it's immoral to allow
>> >> suckers to keep their money" does work for them. And their risk
>> >> estimation seems to work pretty well.
>>
>> > You're going to lecture me on the fundamentals of markets?  Oh, boy.
>> > That's rich.  You got any other surprising things you learned at
>> > school today?
>>
>> Oh, you "know" software security, medical production, software
>> production,
>> markets, cold war,  Edsger Dijkstra, NASA, and whatever else. Typical
of
>> high school kid. And, unfortunately, like majority of high school kids
>> you can't read.
>>
> 
> I can read and write very well.

It's apparently disputable.

> Since English is probably not your 
> first language, I won't comment on your skills.

I never claimed I could write well. But I a least try to stick to the
subject.

> 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.

> I very well knew that. 

So you intentionally tried to twist..

> That's why I put stars  
> around the reference.  The fact that we are talking about software to
> *****s risk and software that is susceptible to risk is apparently too
> confusing for you,

Nope. But these things have little in common. 

> as you are imagining that I would confuse them as 
> you apparently want to.

Whatever.

> The software that NASA used to *****s risk 
> got wildly optimistic answers.

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

> That says there is something wrong 
> with the methodology to *****s risk.

Risk of what?

> 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.

> 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.


>> > 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.

> 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 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...


Sebastian Kaliszewski
-- 
"Never underestimate the power of human stupidity" -- L. Lang