Re: Intel details future Larrabee graphics chip
- From: "Wilco Dijkstra" <Wilco.removethisDijkstra@xxxxxxxxxxxx>
- Date: Wed, 13 Aug 2008 11:10:20 +0100
"(see below)" <yaldnif.w@xxxxxxxxxxxxxxxx> wrote in message news:C4C80556.F5560%yaldnif.w@xxxxxxxxxxxxxxxxxxx
On 13/08/2008 01:26, in article pSpok.221137$IP7.99316@xxxxxxxxxxxxx, "Wilco
Dijkstra" <Wilco.removethisDijkstra@xxxxxxxxxxxx> wrote:
Often you have no choice but to use what the language/runtime system supplies.
There are lots of different ways to implement these features. It's impossible
for one standard implementation to be optimal in all usage scenarios.
That of course, is true of unchecked languages as well (in spades).
Quite true. But you can easily replace part of the libraries with your own
application specific versions (eg. fast memory allocation), something which
becomes much harder if a feature is built into the language (or if the language
doesn't support C-style pointers).
Usually all arrays/integers/pointers are checked, so
you always pay the cost of checks that
cannot be optimized away but which you know are not needed. Additionally
these checks generate exceptions which block compiler optimization and use
large unwind tables and runtime support routines (bad for code size).
Languages with these properties are inadequate for software engineering.
Their specific faults do not prove your general case.
Most "safe" languages have these properties unfortunately. For example runtime
checks require complex exception support (Pascal just terminates the program
when a check fails, which is NOT safe behaviour).
To give an example, once someone rewrote a command-line parser from C
into C++ STL. It suddenly became a major performance hog due to doing lots
of small string concatenations. A specialized string class (or just plain C)
was 25-50 times faster.
Someone used an inappropriate algorithm and data structure. So what?
It was a translation from low-level C into OO C++, so was quite reasonable to
use STL strings. My point is there can be a huge difference in performance
between a high level feature and a low-level one, so it's a big issue if you
don't have the low-level support when you need it.
In a language that forced you to use garbage collected
builtin strings we would have had a hard time to work around it.
That would certainly be an inadequate language for software engineering.
Are you familiar with Ada?
It does not have the defects you complain of above.
It has been a while since I looked at Ada, but from what I remember it did have
various of the issues I mentioned.
Wilco
.
- Follow-Ups:
- Re: Intel details future Larrabee graphics chip
- From: (see below)
- Re: Intel details future Larrabee graphics chip
- From: Nick Maclaren
- Re: Intel details future Larrabee graphics chip
- References:
- Re: Intel details future Larrabee graphics chip
- From: (see below)
- Re: Intel details future Larrabee graphics chip
- From: Wilco Dijkstra
- Re: Intel details future Larrabee graphics chip
- From: (see below)
- Re: Intel details future Larrabee graphics chip
- Prev by Date: Re: Intel details future Larrabee graphics chip
- Next by Date: Re: Intel details future Larrabee graphics chip
- Previous by thread: Re: Intel details future Larrabee graphics chip
- Next by thread: Re: Intel details future Larrabee graphics chip
- Index(es):
Relevant Pages
|
