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

On Tue, 16 Jun 2009 15:28:09 +0100, Martin Brown
<|||newspam|||@nezumi.demon.co.uk> wrote:

John Larkin wrote:
On Mon, 15 Jun 2009 10:20:15 GMT, Jan Panteltje
<pNaonStpealmtje@xxxxxxxxx> wrote:

On a sunny day (Sun, 14 Jun 2009 18:08:47 -0700) it happened John Larkin
<jjlarkin@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
<hu6b35h4tvjo5mbca570uabhrn961b30q8@xxxxxxx>:

On Mon, 15 Jun 2009 00:43:48 +0100, Nobody <nobody@xxxxxxxxxxx> wrote:

On Sun, 14 Jun 2009 14:07:27 -0700, John Larkin wrote:

A language which allowed applications to be written in half the time at
the expense of requiring double the processing power would be a net win in
most cases. More generally: for time/N and CPU*N for quite a wide range of
N, IMHO.

And any Luddites wanting to run hand-crafted asm/C would still reap the
benefits of the "bloat" forcing hardware prices down.
I still do embedded stuff in assembly, but mostly because I like it. I
doubt that any other language would save me a lot of net time, because
I spend more time figuring out what to do than I spend coding.
BTW, I'm not knocking asm/C for embedded and systems programming.

I just think that the fact that C/C++ is the industry standard for writing
multi-million-lines-of-code packages is crazy.
Yes. It was an unfortunate accident.

Not necessarily a fault
on the part of a specific entity or project, just the fact that the
industry collectively hasn't managed to dig itself out of the hole.
The language and the culture are entangled. A real mess.

Maybe somebody will invent a better language and an institute to train
truly good programmers. The demand will be impressive.

But programming languages that are known to be much safer that C/C++
already exist. However, industry has chosen to go the low reliability
and cheap route as a commercial decision. And it seems to be what the
mass market wants.

Safety critical software for trains, ABS brakes and engine management
tend to be developed in a much more conservative and controlled
environment. But that makes it more expensive there is a steep learning
curve and a shortage of qualified engineers to do the work.

Quite the understatement.

John
Although purely from a philosophical POV you both have a point,
I think you are overlooking the obvious.
Buildings are still build with bricks, some with concrete.
There is also some pre-fab going on.

The versatility of the bricks and concrete allows endless creativity and solutions.

Yes, but civil engineering and construction are mature processes. When
we did the seismic retrofit to our building, registered professional
engineers did the math and other professional engineers checked their
work and signed off on it. The re-rod was inspected before the
concrete was poured. Every load of concrete was sampled and the
samples aged and tested to failure. It was fixed-price and happen
on-cost, on-schedule, and came out right. Putting buildings together,
even daring designs, is a mature process, so mature that buildings
rarely fail, and when they do it makes world headlines, and
commissions are set up to discover why and to make sure it doesn't
happen again.

The Blade of Light bridge in London was the most recent example of a
civil engineering design that by pushing the envelope fell foul of
entrainment resonance effects. It didn't help that they ran a walking
race across it on the first day. Once it started bouncing slightly
people lockstepped and the oscillation amplified alarmingly.

Or another was the new Paris CDG terminal collapse.
http://www.newscientist.com/article/dn5027-innovative-airport-terminal-collapses-in-paris.html

It is also worth pointing here that virtually all civil engineering
projects make extensive use of CAD and finite element analysis
*software* to draw up the designs, visualise and simulate them before
any construction takes place.

Electronic hardware design is similar: we predict performance and cost
and make it happen withour drama. The creativity is in the
architecture and the performance, and less in the implementation.[1]

And again without the CAD software and the layout *software* tools you
would be back to the dark ages of clear coloured sticky tape and tedious
manual layouts. Modern CPU chips would be impossible to design by hand
without the aid of software tools.

Software, on the other hand, is an immature and chaotic handcraft that
anybody can do and nobody can control. Billion-dollar software
failures are so routine they aren't even news.

Billion dollar software failures are still quite rare and high profile.
Very large projects that push the boundaries are often high risk. They
become very high risk when the project managers are clueless.

By track record billion dollar software failures are the majority from
what i read, and mostly swept under the rug. Do you have comp.risks
in your regular reading list?

It won't always be that way.

Agreed. But the best prospect of getting an improvement is for the
future generations of languages to move more towards specifying
accurately and unambiguously *what* a program is supposed to do. And
then leaving it to the compiler writers to convert what into how. This
is already happening to some extent in that current Pentiums translate
the x86 assembler code on the fly into internal parallelised micro-ops
and then executes those. A tight loop executes the micro-ops from the
tracebuffer.

This micro-property has nothing to do with the macro-property.

One language I use is capable at compile time of detecting by dataflow
analysis if there are any paths that could allow a variable to be used
before it is initialised. If there are then by default it issues a
warning and compiles a hard trap at the requisite point. I have promoted
that particular warning message to a compile time error.

Same with C (C++ is a speech disability and it does not count, I dunno C++,
as it is only for those who cannot program, but C is really easy, and) there are a zillion
C libraries (say pre-fab solutions) or even libraries written in other languages that
have a C interface, so that are a few of the reasons that C is so omnipresent.
Portability is an other one (if written in a sane way), now everybody uses gcc and libc...
portability is great.
That is great compared to other languages.

The bad code and the bugs are portable, too.

Not quite. Usually you do learn something new whenever a program is
ported to a new environment or compiler. And unlike hardware and
physical objects software becomes more reliable with age and runtime
experience. It does not wear out in the same way that mechanical things do.

True, it has different wear out mechanisms, like APIs that become
depreciated then obsolete (and a lot like some hardware interfaces
that required software interfaces).

I remember I received so crypto code for X86 may years ago, it did what could not be done,
but some of it was in x86 asm.
I spend a little time changing the asm to C, and low and behold it would all of the sudden
run on any processor anywhere.
And it actually was just as fast give or take a few microseconds.:-)

C is a standard solution, if you can analyse a problem, and think of a step by step way
to solve it, then you can program it in C.

Some people can, especially for small problems. But small problems can
be coded many diffferent ways that all work. Big software systems have
about a 50% failure rate.

But the problem is with the size of the project and the inadequate use
of tools to support the development. Often the lack of anything even
vaguely resembling a self consistent specification at the outset
condemns the thing to fail.

If you started to build a house by showing the customer the newest solid
gold bathtaps you were planning to use in the master bedroom ensuite
bathroom and hanging the rest of the house of that he would thing you
were crazy. The same sales pitch works all too well for bespoke software.

Consider the buyers in the two cases.

[1] Which brings up an interesting point: electronic design
increasingly involves connecting ic's and boxes; we have moved up the
abstraction stack from the discrete tube and transistor days.
Software, in theory, also does a lot of connecting of standard boxes.

Would that this were true in practice. There are plenty of standard
libraries that are well tested and developed by experts NAGLIB for
instance being a very old example. But there are also no end of
programmers that try to roll their own code without understanding any of
the intricacies. Your fixed seed N-R sqrt being a case in point.

To really rub the point home, look at proliferation of HTTP based
download managers (read data pirates) that are being created instead
of using safe, well tested, reliable, and restartable FTP which is
included on all current major OS's. What are those webheads thinking?

The difference is that an opamp has 3 active pins and comes with a
20-page data***. A DRAM has a 200 page data***, appnotes, and apps
engineers available to answer any questions. Most chips have eval
boards and free human support available.

Some software has similar levels of support although not free.

I read some Windows module code. There's a standard form at the top of
every subroutine that the author is supposed to fill out. One field is
"Desciption of function" which was often filled out with useful info
like "What it says." So the documentation is the code itself.

You may have been unlucky. Some programs are better written than others.
The executable code is never the documentation.

There is no silver bullet for programming found so far. You can write
unreadable and unmaintainable programs in any language - even Cobol.

Imagine building a big system out of undocumented ICs.

Many ICs do have a few quirks that are not mentioned in the data***.

But there is a point here that software has not yet reached a point
where the equivalent of Whitworth in mechanical engineering has
standardised screw threads from the infinity of possibilities to a
workable subset. Buying in well documented and tested modules is not
common practice (in part because you can be left up the creek if your
supplier goes under). JPGELIB is an example of a free library that is
very well field tested now.

Guess why open source is getting so popular now.

A posteriori we can say of various DOS or Windows versions which ones
were good and which were dogs. A bit like medieval cathedral builders if
it is still standing after 5 years then it was a good one.

And there are bazaars that have been operating for over a thousand
years.

Regards,
Martin Brown
.

Quantcast