Board index » delphi » Itanium goes x86-64...

2005-07-28 02:04:47 PM
delphi198
...or EM64T as Intel calls it
support.intel.com/performance/
IA-64 looks more and more like a dead horse.
Eric
 

Oliver Townshend
 

In a few months now, there will be another long expected demonstration$
of spinmeistery from Intel when they'll {*word*241} off the P4 line to make
room for the sons and daughters of a Pentium M.
Eric
 

Eric Grange wrote in <XXXX@XXXXX.COM>:
support with EM64T support. The Inquirer had an article on this as
well, and I seem to recall it saying something about translating the
machine code at runtime from x86/EM64T to IA64 (thus removing any
emulation penalties). That sounds really interesting, and depending on
how it performs, could make IA64 systems viable for more generic tasks.
(Assuming the prices for IA64 systems ever come down, heh).
Will
--
Want native support in Delphi for AMD64/EM64T? Vote here--
qc.borland.com/wc/qcmain.aspx
 

paralellism to offer any kind of performance, which involves a lot of
complex compilation work.
Eric
 

Eric Grange wrote in <42e9e153$XXXX@XXXXX.COM>:
the compiler has access to more information (the source code) than the
processor. it is in a better position to determine when and what to
execute in parallel, which is kinda the whole point of IA-64's
architecture I think.
As far as I am concerned tho, Intel dropped the ball on bringing IA-64
to the desktop. They might be able to try it again in 8-12 years, but I
think x86-64/EM64T/AMD64 are here to stay (and is precisely the reason
Borland should immediately support this de facto 64-bit standard).
Will
--
Want native support in Delphi for AMD64/EM64T? Vote here--
qc.borland.com/wc/qcmain.aspx
 

Oliver Townshend
 

never been able to keep up to out of order processor in practice.
That's for two reasons:
- requires very detailed knowledge of CPU timings and behaviours,
practically either a CPU simulator or a per-model compiler,
f.i. latencies of a P4 2 GHz and those of the latest P4 3 GHz
are different for a variety of instructions, and in a variety
of situations, a compiler designed for P4 2GHz wouldn't be so
hot on the 3 GHz
- compiler has to compile at a very fine granularity with no
knowledge of the CPU I/O states, if it introduced an explicit
parallelism between 4 values f.i., and one of these isn't in
the cache, then the processing of the 4 values will be stalled
(while in an out of order CPU, the 3 others stand a chance
of being processed)
- compiler-specified branch prediction means branch prediction doesn't
adapt to the data being processed (and more often than not,
the compiler will not have much clues on that front), compiler-
specified prefetching means just as much risk of being wrong.
The 2nd & 3rd points are a little more far reaching than they look:
since instructions have to be regrouped in parallel execution blocks,
stalls can happen across logically unrelated bits of processings (that
where just regouped together because the compiler made them so).
All in all, this means the compiler can do a good job only when the
workflow is deterministic and independant from the data being processed:
f.i. summing up values or multiplying large matrices will suit it
perfectly, but sorting a bunch of string values will be a complete
nightmare when using classic string comparison and sorting algorithms.
Eric
 

undervolting), multiple low-power, high IPC cores could just be
what the doctor asked for on the desktop where those heatsinks
and power specs have been getting way too ridiculous lately,
I long for the days when passive cooling was the norm.
Eric