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

Robert Myers wrote:
>> > I have very little sympathy for the concerns of software developers.
>> > We'd be much better off with longer software development cycles so we
>> > had less bad software.
>>
>> ROTFL!
>>
>> You got things 180 degree reversed from the reality. The reality is
that
>> making software development harder won't make better software product
nor
>> will it influence software development cycles.
>>
>> This is a relatively common misconception among those who're clueless
>> about sofware development that length of development cycles pre se has
>> any meaningful effect on final product quality.
> 
> You made an erroneous inference from what I wrote because you
> seriously underestimated how little I think of software developers.

Who cares what some clueless newsgroup poster thinks.


> If software developers are *slowed down*, there will be less bad
> software because there will be less software.
> 
> It didn't *have* to turn out this way, but it did, and *you* are part
> of the problem because, apparently, you think you know how to write
> good software using languages and tools currently in use.
> 
> I may be wrong.

You are.


> If you are writing in a language and using tools that 
> allow checking of your programs for formal correctness, and if you
> actually use those tools, please accept my apologies.  Otherwise, you
> are just another member of the club of gunslingers that call
> themselves software developers and talk big, probably because they've
> spent too much time blowing people away in video games.

You're clueless about software develompent process. Contrary to you I know
how to do formal verification of a software and do it when it's *needed*.
The im****tant point here it's *needed* exceptionaly rarely. Thats because
is that formal verification is:
1. very expensive
2. does not guarantee total correctenss -- it only reduces chances of
error
and that reduction is in reality directly pro****tional to cost increase.

It makes sense only in life critical systems (where cost of any hard error
is measured in millions). There it's in fact the preferred way (and the
cheapest one, as Lockhead's experience shows). But in other situations
it's
simply too expensive.


>> There is multitude of software
>> systemes where there are strong requirements of simultanous high
quality
>> and short development cycles. And those requirements are met.
> 
> rotfflmao.  The extra f is intentional, as I'm sure your humor is not.

Go buy a clue and stop making idiot of yourself publicly.


>> Im****tance of
>> cycle time is conditional on actual development methodology employed.
> 
> Once again, if you are using tools and methods that practically no one
> actually uses, please accept my apologies.  If you are relying on your
> own personal brilliance and rigor, or that of your colleagues, you are
> deluding yourself.

No, I'm relying on cost of software production vs cost's of errors times
times their expected probability of occurence during lifetime of the
software.
Making software immune to errors costing 1e+9$ with probability greater
that
1-1e-4 (that is four nines) during 10 years lifetime should not cost more
than 1e+5$ (that's about 1 man-year spent on improving quality). If it
costs more it's time to cut corners and increase error probability
reducing
production cost.
And even then it's pointless to run that software on hardware with fault
probability worse that that of software (i.e. not for home use, nor small
company -- your standard PC will die with probability well above 0.5 not
below 0.0001 within the timeframe (even if you're doing regular
professional system maitenence and exchange all parts on planed shedule).
Then all of that must be immune to operator errors -- also impossible in
home or small and middle sized business environment.

So what you propose if a horrendous waste of time and money. It makes no
sense whatsoever.


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