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

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.

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.

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]

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.

It won't always be that way.



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.


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.

John

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

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.

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.

Imagine building a big system out of undocumented ICs.


.

Quantcast