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

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.

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.

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

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.

Regards,
Martin Brown
.

Relevant Pages

  • Re: Do you have a Knowledge Officer?
    ... opinion, unless he supports it with verifiable facts and credible ... Sure, it's more accurate, but debates don't turn on the accuracy of facts, ... programmers are generalists having control over the ... is actually the opposite - it means that you have an intermittent bug ...
    (comp.lang.cobol)
  • Re: Whats right with FORTH and wrong with c.l.f.
    ... regular language isn't a problem, but even for that language you have ... might be more popular with Forth programmers. ... Or I might use some existing libraries. ... if one innocent soul finds a bug in the ...
    (comp.lang.forth)
  • Re: PL/I string representations (was Re: To Richard Heathfield: enoughs enough)
    ... It is a low-level assembler language written in a high ... > Few missions are speed critical, no matter what programmers may ... remember that the majority of computers are not even a thousandth as ... Mr. Nilges might want to retell the ...
    (comp.programming)
  • Re: Overview Of New Intel Core i7(Nehalem) Processor
    ... programmers raving about Java and stuff, ... Programmers who really enjoy working with computers ... So the ideal programming language is Cobol, ... automated checker to find my bugs. ...
    (sci.electronics.design)
  • Re: [Lit.] Buffer overruns
    ... > in any memory-safe language. ... it would be caught by truly mindless bounds checking. ... > So human programmers might not reliably catch this bug. ...
    (sci.crypt)
Quantcast