Slashdot Mirror

Trimaran, originally developed for the Itanium, has also proven to be an extremely capable compiler for parallel processors.

GCC? On Itanium? Optimized quite well? Whatever. Check out Trimaran for the HP/Illinois/NYU compilers which basically inspired Itanium.

I work on EPIC compilers and I concur on every one of your observations. The caveat is that every EPIC compiler optimizations is applicable to superscalar processors too. Hence the only reason why EPIC would beat superscalars is the reduced complexity of the processor itself which would (hopefully) make it cheap and fast.

In theory EPIC compilers should give amazing performance. In practice due to pointers, aliasing and lack of interprocedural optimzations they dont. It is interesting to note that Java, because of lack of pointers produces impressive code for EPIC processors and is highly amenable to optimizations targetting EPIC.

"There is only one company that has ever made a good VLIW compiler: TI, again."

I would like to think TI and Us .

I work on EPIC compilers and I concur on every one of your observations. The caveat is that every EPIC compiler optimizations is applicable to superscalar processors too. Hence the only reason why EPIC would beat superscalars is the reduced complexity of the processor itself which would (hopefully) make it cheap and fast.

In theory EPIC compilers should give amazing performance. In practice due to pointers, aliasing and lack of interprocedural optimzations they dont. It is interesting to note that Java, because of lack of pointers produces impressive code for EPIC processors and is highly amenable to optimizations targetting EPIC.

"There is only one company that has ever made a good VLIW compiler: TI, again."

I would like to think TI and Us .

"By placing the burden of parellelism determination and instruction scheduling on the compiler, intel made the compiler writer's job much harder, but at the benefit of increased performance."

" I think the next few iterations of itaniums _will_ beat the AMD 64-bit chip on bechmarks"

These are highly debatable statements. I work on EPIC compilers and simulators. In theory EPIC compilers have a huge "window" into which they can look for parallelism when compared to superscalar processors whose hardware look at a small window for parallism. However in practice, usage of pointers, aliases, lack of interprocedural optimizations etc etc makes EPIC slower than Superscalar. Also all compiler tricks for EPIC are applicable to superscalar too.

The first generation of AMD-64 will beat itanium hands down. The reason Intel will eventually win is because EPIC processors are *way* to easy to design and implement than superscalar processors. That is the only reason Intel is shifting to EPIC .

-Dracken.

A bunch of scientist have been working on compilers for EPIC processors for quite some time now.
Check out the Trimaran project. They have a version for Linux.

all it takes ...

sorry I was @ work and I know that alot of people where not familer with HP and IA64 I was trying to point out the fact that HP worked on IA64 more than intel have done most of the research has been done with them

its intresting to notice that alot of DATA centers where they process data run HP PA-RISC and HP-UX

HP-UX is a dog just because you find that nothing you would think would be standard is the manual might as well read

THE STANDARD IS ... but it was SLOW so we did THIS ...

a good referance is the trimaran project

http://www.trimaran.org/

which has been Ported to LINUX now you too can mess with compilers !


I am under NDA over the compiler but I can tell you that they have been very clever with the registers makeing full use of the hardware and that
A) the compiler sees most of what the programer wants to do so can preform most of the checking

B) the hardware has good V. good prediction built in and the compiler tells it what it thinks is going to happen

the compiler is the most important part of the system this was learnt from OS2 and from GCC how much does the GNU Compiler Collection get used !!

regards

john

(bit upset about the troll)



a poor student @ bournemouth uni in the UK (a deltic so please dont moan about spelling but the content)

what about their PA-RISC machines ??

Alan cox has a machine in his study and belive me HP-UX sucks as a user O/S

not bad as a server tho

come on HP sort it out I would love to see what happens when they sort out a compiler for these PA-RISC machine 450MHz and 64 bit with prediction like IA64

do it HP crush M$ and sort out linux
HP is one of the BIG boys and they all seem to go to HP for their research when it all goes pear

like with intel and IA-64

ah well in for a long wait but go to Trimaran to see what compilers should be doing !


a poor student @ bournemouth uni in the UK (a deltic so please dont moan about spelling but the content)

intel has woken up because they have this in their labs for a V long time !

the idea that they could sort out unix world by just giveing out some of their tecnology and generate good press

what we need is for IA-64 stuff to be sorted out for instance the trimeran could be ported over to IA-64 it would help alot for ol gcc

and how about sorting out floating point with 3d now or streaming instructions ???

ah well good move well done Intel

referances GO TO IT >>>>> Trimaran
a poor student @ bournemouth uni in the UK (a deltic so please dont moan about spelling but the content)

First, before everyone jumps in and says "Intel will never get there because the compiler will never get there," please don't forget that some shipping devices are already there.

Quite simply, EPIC allows a compiler to tell the hardware ahead of time where it knows parallelism exists, so that the silicon (which is finite) doesn't have to hunt for it. Compared to the rate at which silicon must make scheduling decisions (at 800MHz, that's 1.25 nanoseconds), compiler time seems infinite.

Granted, compiler time is not infinite, but for performance-critical applications, it is quite large. The Texas Instruments TMS320C6000-family of DSPs, for instance, rely on compilers and assembly optimizers in order to eek out that last bit of performance, and as any DSP engineer will likely tell you, its usually worth it. Cycles saved in one loop are cycles that can be spent elsewhere on value-added features, leading to a more valuable product.

This points to the real fundamental problem as I see it, which is that the current VLIW darling in the industry is in the embedded world. Why should that make a difference, you ask? Because the embedded developer is the one most likely to take advantage of the raw capability that an exposed parallelism architecture can provide.

Merced's biggest problem lying ahead is the fact that workstation-class code does not naturally exhibit large amounts of parallelism. While I was attending MICRO-31, I heard someone remark about how most code looks like a series of 5-10 instruction bursts followed by a jump. ICK!!

Embedded programmers generally seem willing to learn whatever it takes to get their product running in the fewest MIPS (so that they can either use cheaper parts or provide more features), and so are often willing to jump through a few hoops to help out the compiler in order to get the parallelism they desire.

Workstation programmers, on the other hand, are interested in the much bigger picture (since their applications are much larger and tend to have larger life expectancies), and so code tends to be human-friendly and not compiler friendly. (Certain heavily-traveled code paths in the Linux kernel being a noteworthy exception.)

The point is that the Merced compiler will ship with alot of amazing compiler transformations, but very few of them will be effective at translating the hopping, skipping, and jumping nature of your typical general-purpose database-ish looking code into highly parallel performance-oozing EPIC instructions, at least straight out of the gate.

Merced will inherently provide big performance wins to the compute-farm customers (your big engineering shops that currently use networks full of Sun or HP workstations to crunch VHDL, Spice, or whatever simulations around the clock), as these applications end up reducing to huge matrix manipulations and numeric crunching galore -- oozing with parallelism. But Merced will be hard pressed to feed up web pages or database queries much faster than any other architecture, unless it's able to massively crank its clock rate due to losing the shackles of the instruction scheduling hardware.

Anyway, those compiler nuts in the crowd might find the following links useful and informative.

• The Rocket Project -- ILP research at Michigan Tech University
• VLIW Architectures -- a description of VLIW that's part of a larger presentation about VLIW compiler techniques.
• The Trimaran Research Compiler -- HP's research compiler that was supposedly used in development of the architecture that begat Merced.
• EE Times -- article which describes the release of Trimaran and includes a diagram showing the relationship of architectures from Superscalar to VLIW/EPIC to TTA.