Re: Overview Of New Intel Core i7(Nehalem) Processor

John Larkin wrote:
On Wed, 17 Jun 2009 22:09:52 +0100, Martin Brown
<|||newspam|||@nezumi.demon.co.uk> wrote:

John Larkin wrote:
On Wed, 17 Jun 2009 13:05:23 +0100, Martin Brown
<|||newspam|||@nezumi.demon.co.uk> wrote:

You mean like your impossibly fast converging fixed seed N-R sqrt routine that gets entirely the wrong answer for values that trigger the false solution sqrt(K*2^32+x) for any K. What was that? 12 instructions with one *major* bug in it returning results that are obviously incompatible with the invariant boundary condition that for
input x<2^32 sqrt(x) output < 2^16

Undetected overflows could occur and provided y*y MOD 2^32 = x
the routine would seem to converge quickly on a wrong answer.

What's the specific input integer that fails?

You have asked this before - are you hoping for a different answer now?

http://groups.google.co.uk/group/sci.physics/msg/a3736dfa6166babc?hl=en&dmode=source

ISTR you were boasting about never having solved a quadratic when you originally posted this spurious claim of a far too fast converging N-R sqrt from a fixed seed of A=200. It will fail badly when the first iteration gives a value of the form N*2^16 (N>0).

Algebraically it is easy enough to prove it will happen first when

2^16 + 1 = (y+A^2)/2A
hence
y = (2^17+2-A)*A = (131072+2-200)*200 = 26174800

Successive iterations bounce between 200 and 2^16+1 forever. All input values above this are at risk of failing to converge to a true root.

It isn't like testing every possible value of a 32bit sqrt(x) routine is impossible. And several better methods with a benchmark timing and verification program were posted in comp.software-eng a few years back.

I did simulate it for accuracy over my known numeric operating range.
I know that it doesn't converge for values that can't happen in my
system. It hasn't caused any problems.

You didn't when you posted it. That is a post hoc rationalisation after being caught out. Futzing about with the numbers was the phrase you used at the time - this does not inspire me with confidence.

So your professed "bug freeness" assertion rings hollow. I reckon the term "Larkin bug free" should enter the Computer Science lexicon for software that has subtle or not so subtle bugs but which the author insists vehemently is "bug free".

We have had bugs in a small fraction of our first-shipped embedded
products, a couple percent maybe... less than a bug per year. And

Good for you. But I have a distinct feeling that your software has a low irreducible complexity compared to things like operating systems and major applications.

those few bugs have been mostly minor things. The culture of "all
software has bugs" is self-fulfulling. The culture of "we don't allow
bugs" can, done seriously, result in the great majority of products
being shipped totally free of hardware or software bugs. The people
who build jet engines understand this.

Problems in jet engine fadecs are not unknown. The UK currently has about 8 Mk3 Chinook helicopters that due to third rate f*ckwits specifying them are unable to fly safely in cloudy weather. Not good in the UK. They are still grounded.

http://computescotland.com/2121.php

The Mk 2s were not much better. A known fundamental engine error condition probably cost around two dozen of our best antiterrorist security specialists their lives. The military enquiry blamed "pilot error" but no-one else does. When your best test pilots refuse to fly the thing putting one into service to move irreplaceable personnel on a single flight is utterly insane. When I was in a large company there was a strict limit on the number of senior personnel travelling together.

http://www.independent.co.uk/news/test-pilots-feared-chinook-had-engine-fault-1323564.html


Most commercial software is, by my standards, garbage. PADS v5 seems
to be bug-free, if sometimes arcane. Small nice apps like Irfanview
and Crimson Editor and Appcad and LT Spice seem very solid, so we
prefer them to other stuff... not to mention that they are free. The

Xilinx stuff, Adobe, Microsoft, most of the packages written by large
teams, are usually terrible.

Hmmm... it's looking like the more you pay for software, the more bugs
it will have.

The faster it has been rushed to market the more bugs you will have.

The purpose of the automated checkers and other tools is to make sure that effort is concentrated on the areas of software where bugs are most likely to be lurking undetected. If you are careful then it won't find many but these tools can find bugs in code that has run apparently bug free for a decade or so without reported errors.


That's fine as long as it's a supplement to designing and reviewing
the code carefully. No automation and no rational amount of testing
can find bugs that result from incorrect understanding of the problem.

If the original specification of the problem is broken or inconsistent then all bets are off. A lot of the bigger software failures are in part down to sabotage in the initial requirements analysis.

If the availability of automated checking tools causes the coders to
check their work less, they may make things worse. And a language and
a compiler that allow bad coding - like wild pointers and memcyps -
and that need supplemental checkers seem like a bad idea to me.

But if the type safety is built into the language along the lines of a lightweight Ada and assumes that if a thing can go wrong it will then it is possible using the compiler parse tree to detect at *compile* time a lot of the situations that could lead to runtime failure. I see no point at all in letting something escape detection at compile time and I would much prefer to see it caught at the specification stage. That is why I believe we should be heading for languages that specify what to do rather than how to do it.

There are a whole bunch of practitioners out there that apply C casts to argument lists pretty much at random until the thing compiles. Scary...

Regards,
Martin Brown
.

Quantcast