PathScale Open-Sources The EKOPath 4 Compiler Suite

[fithisux]

The software vendors are getting it but hardware vendors are not

5) Trust is a personal thing. I work at PathScale and clearly biased. Continue to track our open source progress and make the decision for yourself.[/QUOTE]


Pathscale proves once more that the hardware vendors don't get it. Softwarevendors are open but they need open platforms. We need PCIe cards with co-processors that do OpenCL/OpenGL/OpenAL in software via a standardized interface with the card (to feed it with commands). Audio and gfx chipsets then could be simplified. For example I can buy a standardized framebuffer (VESA) with simple 2D acceleration (like a FireWire/USB PCI card) to interface to my various vga/dvi whatever monitors and use the CPU or the accelerator card to do 3D. NO 3D in GFX cards. Use the CPU (a six core phenom e.g. ) or buy an accelerator card (even for audio signal processing) and retarget your compiler . Go go go go PathScale.

[simonbcn]

There's really too much confusion about Open64 + EKOpath. To set the facts straight.

EKOPath is a "fork" of SGI's Pro64 and never has imported code from Open64. Partial sources for EKOPath were previously available, but not all. Large portions of those sources were merged into Open64 as a result of previous PathScale management not supporting open source. Slowly the PathScale ship is changing direction and trying to build a real community of users/developers.

This doesn't match with the information provided in the website of Open64:

Open64 is the final result of research contributions from a number of compiler groups around the world. Formerly known as Pro64, Open64 was initially created by SGI and licensed under the GNU Public License (GPL v2). It was derived from SGI's MIPSPro compiler.
....
Open64 has been retargetted to a number of architectures. Pathscale modified Open64 to create EkoPath, a compiler for the AMD64 architecture...

[ChrisXY]

I'm not sure what to use for -march since "native" is not accepted.

"march=native" should definitively do something. If not something useful, maybe just accept and omit it silently because there might be many configure scripts out there that assume it.
I tried for example vlc-git.

(but doesn't compile anyway:

### Compiler Error during Writing WHIRL file phase:
### Add_Init_For_WHIRL: unexpected static init tree
make[4]: *** [network/libvlccore_la-udp.lo] Fehler 1

"Fehler"=Error

[jrch2k8]

Cheers for the quick response. About what I figured, but never hurts to ask.

c++ 2011 is still too new but you could use gcc 4.6 and try lots of flags combinations to get closer to ekopath and having c++ 2011

the most important thing for heavy performance apps is not just some magic compiler but to code properly and use the hardware accel properly (sse, avx, etc) and be strict checking your cache alignement and when possible reduce the use of loops to the minimum possible or at least try to beef them up with as many operations as you can safely put every cycle

[mirv]

c++ 2011 is still too new but you could use gcc 4.6 and try lots of flags combinations to get closer to ekopath and having c++ 2011

the most important thing for heavy performance apps is not just some magic compiler but to code properly and use the hardware accel properly (sse, avx, etc) and be strict checking your cache alignement and when possible reduce the use of loops to the minimum possible or at least try to beef them up with as many operations as you can safely put every cycle

I'll be using gcc4.6 once it comes out of hard masking on gentoo. I'm only playing with the new C++0x features for the sake of learning right now, though admittedly it's nice to see threading finally be part of STL.

The first line I gave to embedded C students: know your hardware.

[jrch2k8]

The first line I gave to embedded C students: know your hardware.

the wiser first line ever. ppl don't get that most of the time cuz they assume the OS should do something about it magically, damn microsoft and their for the lazy interpreted languages (.net, vb, etc)

[ivank]

Any pathscale representatives here?

I've tried to use EKOPath 4 nightly build published currently on pathscale's site to compile one of my projects... it didn't get very far and crashed:

### Assertion failure at line 2183 of
/var/jenkins/workspace/Linux_Packages/src/compiler/src/be/vho/vho_lower.cxx:
### Compiler Error in file city.i during VHO Processing phase:
### op OPR_RROTATE unexpected in vho_lower_set_st_addr_info

Whom should I sent my bug reports to? I'm not asking for commercial support, just want to let developers know about the problem. I've tried [email protected], but it basically sent me in return a link to http://www.pathscale.com/buy.html, which makes me think bug reports from non-customers aren't wanted there...

[FireBurn]

I'll be using gcc4.6 once it comes out of hard masking on gentoo. I'm only playing with the new C++0x features for the sake of learning right now, though admittedly it's nice to see threading finally be part of STL.

The first line I gave to embedded C students: know your hardware.

I've been using it for a while, there's only a few packages I've personally has issues with.

Chromium I have to patch manually - I'm not sure why it's not been fixed upsteam yet or why the patch hasn't been added to the ebuild

NSS won't build, I think a solution is being worked on

LibreOffice won't build, I'm not sure if 3.3 fixes this or not

Which is far fewer issues than I've had with the switch to kernel 3

[Nobu]

Lets see...
1.) 'EKOPath is a "fork" of SGI's Pro64' <-/-> '[...]modified Open64 to create EkoPath'
2.) Pro64 became Open64, which 'was initially created by SGI' <-> 'EKOPath is a "fork" of SGI's Pro64'

So, either...
a.) EKOPath is a "fork" of Pro64 and is very similar to Open64 because of their shared heritage.
b.) EKOPath is a fork of Open64...because Pro64 was renamed to Open64?
c.) EKOPath is a fork of Open64...period.
d.) ...Eh?

[pszilard]

Remember, all of these tests are computational in nature, and only in a few of them do you see the massive gains from building with pathcc. I do not think it will help that much for normal end-user desktop software like KDE SC or Firefox... But, maybe they can speed the Folding@home supercomputer up by using EKOPath to compile gromacs.

As in Gromacs the great majority of the run-time is spent in hand-coded assembly kernels (SSE/SSE2 on X86/AMD64/X86_64), I doubt that EKOPath can give much speedup wrt gcc. For the same reason there is really not very much difference between the Intel C compiler and gcc (at least recent versions) either. Still, it would be interesting to see if my assumption is right.

When I have a bit of time I'll try and get back with numbers - assuming that i will be able to compile the code.