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

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?

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). 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. Even if you use nothing else McCabes cyclomatic complexity index or CCI shows you where you should be looking for suspicious behaviour. You can take a pretty good bet that once a routine goes beyond a certain complexity level it has the potential to hide bugs. Picking the right places to inspect legacy code carefully improves productivity. YMMV


And since this is sci.electronics.design, my attitude is reasonable.

Even in the real world it is reasonable to want to get the job done reliably and quickly with the least effort. The trade with the devil that has been done in shrink wrap software is for a rush to market with hacked and bodged code. I am not defending these practices at all.

I noticed on Sunday that European paper sizes in my new Word 2007 are completely random and bear no relation to the actual dimensions. It only works correctly when the paper size is set to US Letter (close enough to A4 not to notice) but disastrous when the output is scaled up to A3.
What you see is never what you get. So much for Office 2007 :(

Today they are correct again and if I hadn't taken a screen shot of the failure I would have believed I was hallucinating. Sadly I did not dream it and the nightmare of Office 2007 lives on.

Why anyone would pay full price for it beats me completely.

Regards,
Martin Brown
.

Quantcast