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

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:

John Larkin wrote:
On Sat, 13 Jun 2009 19:37:42 +0100, Nobody <nobody@xxxxxxxxxxx> wrote:

On Sat, 13 Jun 2009 10:47:35 -0700, John Larkin wrote:

One of the great formative and traumatic events of my youth was the
moment that I realized that most programmers aren't interested in
producing usable solutions to my problems, they mostly want to play
mind games with computers, and all they want from me is to pay them
while they do it.
Seems reasonable enough ;)

By which I mean that it seems reasonable enough that a programmer might
*want* such a deal; actually expecting to get it isn't so reasonable,
though.
I was involved with - actually helped start - a company that made
tomographic atom probes, megabuck instruments that rip apart samples
and plot the 3d location and isotopic composition of every atom. The
software challenges are serious. So on one visit, when I heard their
programmers raving about Java and stuff, and not discussing the
physics, alarms went off. $27 million later, it's almost over.
Apart from a few fractionation problems in the plasma or deep pits the
physics for laser ablation analysis isn't too bad. Slicing and dicing
the resultant large spatially resolved isotopic datasets is a distinctly
non trivial problem though. ISTR there is a freeware Java app around
written by one of the universities that does some of the job. It creates
humungous datasets and is slow although I think that is largely an
implementation problem.

Was it an imaging one a la Cameca or a point by point laser ablation?

It works like this:

http://www.imago.com/imago/html/technology/technology.jsp

Atoms can be ripped by pure pulsed electric fields, or by a
combibation of fields and fs laser pulses.

This kit is more suited to fundamental materials research.

The systems I have worked on are for rather more macroscopic pieces of
material like rocks and have been used by some to reverse engineer
chips. Ping it with a highly focused laser and analyse the plasma plume
with quadrupole ICPMS or magnetic sector ICPMS if you are rich enough.

Unfortunately, there's a bit of a balancing act with getting useful work
out of programmers. Programmers who really enjoy working with computers
can be extremely productive and knowledgeable, but are proportionally
harder to keep on task and may be problematic in other areas.
So the ideal programming language is Cobol, where the language is so
uninteresting and so unchanging that the coders are forced to pay
attention to the actual problem, because it's the only interesting
thing around.
It isn't using an uninteresting language that matters. It is having a
language with the right set of tools for the job in hand. Fortran can be
surprisingly good at handling multidimensional arrays of bulk data for
instance and there are a lot of scientific libraries to support it.

I think you are barking up the wrong tree. "Nobody" was close to the
mark with Haskell (which I don't like).

Haskell is cryptic, dense, unreadable, literally "code." That's the
recipe for errors and maintanance problems. It's an intellectual toy,
a racehorse, when we need working dumptrucks.

You are looking at it the wrong way. What we need is an unambiguous
specification and statement of the computational problem where the
compiler can find errors of omission and inconsistencies at compile time
using proof like techniques and dataflow analysis. Mathematical logic is
the only place where proof of correctness exists. For all I care the
notation could be something graphical like Nassi-Schniederman diagrams -
I was once a fan of them and I still think they have some merit. It
comes the closest to expressing software as a circuit diagram that I
know of. These days they are somewhat out of favour...

http://elearn.usc.edu.tt/davidsiguel/Courses/IntroProg/IntroProg10.htm

The big thing in its favour is that the diagrams can be checked by a
domain expert without them having to learn arcane programming syntax.

IMHO Z and VDM are closest to the future path for true safety critical
development methodolgies. Praxis's high intergity Ada subset is another
way that looks promising for practical applications. So far none of
these methods has allowed a company to produce fast bugfree code to
compete against the 1 million monkeys coding C/C++ model.

We need a new generation of
languages where the precise description of *what* has to be done takes
precedence over the how. The compiler writers can then get on with
turning that specification of the program into code that does the job.
And with the right pragmas they can unroll loops and parallelise
anything that isn't interdependent or marked as a strict serial sequential.

Modern CPUs are quite hard to keep busy on all pipelines without data
stalls. This will only get harder in the future as memory subsystems
already limit throughput on most data intensive tasks.

It only cost me six wasted man-months to learn that, so I guess I got
off easy.

What sort of electronics do you design?
I'm a computer programmer, although I've recently started getting into
PICs, which includes building things to connect to them.

When I went to university, I initially studied Electronic Engineering, but
quickly switched to computers. I think that was the right choice; the
design side of electronics is interesting, but I find the construction
part to be more work than fun.
I like the hardware and find programming to be mostly tedious. Which
is why I want to get it over as efficiently as possible, and not have
to revisit it, so I can get back to the fun stuff.
That tends to suggest you would benefit from development tools that help
to isolate common human errors as early as possible.

Wrong, wrong, wrong. I make very few errors, in hardware or software,
because I do most things the simplest, safest way and check my work
carefully. I am responsible for my code and don't expect some
automated checker to find my bugs.

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?


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.


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

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

John

.