Vývojárske nástroje EKOPath 4 uvoľnené so slobodnou licenciou

Spoločnosť PathScale uvoľnila zdrojové kódy svojho doteraz propiertárneho produktu EKOPath 4. Používatelia operačných systémov GNU/Linux, FreeBSD a Solaris tak majú možnosť zadarmo používať všetky nástroje z balíka, ktorého cena za licenciu začínala na sume 1795 dolárov – kompilátor, debugger, assembler a príslušné knižnice (pre programovacie jazyky C, C++ a Fortran).

Produkty spoločnosti sú populárne najmä vo svete HPC, kde konkurujú produktom ako Intel C++ kompilátor. Medzi najzaujímavejšie vlastnosti patrí ISO C99/C++ 2003 a GNU kompatibilita, optimalizácia výsledného kódu zameraná na viacprocesorové systémy a využívanie SSE a AVX inštrukcií.

Spoločnosť očakáva od tohto kroku rozšírenie používateľskej základne a jej následnú participáciu na ďalšom vývoji produktov. Plná komerčná podpora produktu zostáva samozrejme zachovaná.

Podľa dostupných informácií je možné kompilátorom skompilovať po jednoduchej úprave aj samotné Linux jadro a vývojari spoločnosti pracujú na odstránení problémov pri kompilácii QT a Chrome. Benefitom v porovnaní s tradičným GCC je výkonnejší výsledný kód a kratšia doba kompilácie.

14.6.2011 15:03 | kyytaM | Komunita

Komentáře

[stativ]

Koukám, že už mě někdo předběhl. Já chtěl se psaním zprávičky počkat, až budou k dispozici zdrojáky. Ty by (nejspíš) měly být dostupné na https://github.com/pathscale.

Prozatím se všichni musí spokojit s binárkami. Daily build se dá stáhnout tady. Tohle možná bude stable verze, ale nezaručuji to, odkaz jsem se jenom pokusil uhádnout.

[Bedňa]

Aj si to pužíval? Prípadne máš nejaké svoje testy, alebo testy čo robil niekto iný?

[stativ]

No, testy jsou na phoronixu (to Michael trochu prostral, protože to uveřejnil dřív, než PathScale).

Sám jsem ho taky zkoušel, ale jenom u dvou vlastních prográmků. Jeden fungoval bezvadně – ten, co není výpočetně náročný. Druhý se sice zkompiluje bez chyb, ale kompilátor vytvoří špatnou binárku, která způsobí SIGABRT zřejmě už při zavádění do paměti, nebo přinejmenším před tím, než se spustí main().

[Bedňa]

Tak to vyzerá celkom pekne.

[xm]

Wow, benchmarky na Phoronixu jsou doslova dechberoucí! PathCC dává v mnoha případech výsledný kód několikanásobně rychlejší než GCC, je to jak upgradovat procesor

Vím že se orientují hlavně na běh na vícejádrových 64-bit procesorech, používají snad nějakou formu automatické paralelizace? Každopádně tedy GCC dostalo solidně na prdel (i když na druhou stranu s kompatibilou PathCC to není ještě úplně nejslavnější).

[xm]

(btw. je mi jasné, že takto velké rozdíly jsou jen u výpočetně náročných úloh, u běžného programu tak velký rozdíl asi ani zdaleka nebude)

[JoHnY2]

Docela by me zajimal rozdil vykonu u veci jako je PHP, Python nebo PostgreSQL. Kdybych nemel na krku statnice ...

[Bedňa]

Mňa by hlavne zaujímala kompilácia jadra, chcel by som aby bolo dvakrát rýchlejšie

[Miloslav Ponkrác]

Přidejte více jader do cpu.

Každé jádro navíc poznáte, když pustíte kompilaci paralelně.

Sice jádro nekompiluji, ale i středně velké projekty v C++ jsou v cukuletu přeloženy.

Každé jádro jede jeden modul.

[Bedňa]

Nemyslel som kompiláciu jadra, ta je na dvojjadre za hodinku hotová, ale samotný beh Kernelu.

[wtfjakovocode]

nevim jak u tebe, ale u me jadro skoro nic nezere => zrychleni bude minimalni.

[Bedňa]

Na desktope to moc nepocítiš, ale na servery určite áno.

[belisarivs]

Kompilaci jadra na dvoujadre za hodinku? WTF?

To tak brutalne narostlo? Ja bezne kompiloval jadro pro svuj stroj na K-6 II 333 MHz za pul hodiny.

[Bedňa]

Bežalo to ako bokovka a podtaktované na 800MHz.

[Miloslav Ponkrác]

To je jednoduché, PHP × Python dopadne tak, že Python bude pomalejší.

Ovšem benchmarky ovojího musíte udělat se znalostí věci.

Například nedávno jsem viděl benchmark rozhodující, zda jsou v PHP rychlejší řetězce uzavřené v "" nebo v ''. Test spočíval v miliónkrát opakování operace s řetězcem a následné změření času.

Jediný rozdíl mezi je ovšem v překladu do byte kódu, který se děje vždy jednou na začátku. Provádění kódu pak už provádí stejné řetězce, které jsou vnitřně stejné.

Python je ovšem šíleně neoptimalizovaný. Ostatně Rossum, autor Pythonu má roupy, neustále Python překopává. Mezi 2 a 3 verzí i na úrovni zdrojáků, ale každá verze má i nekompatibilní bytekód a další. Tedy nějaká slušnější optimalizace rychlosti Pythonu je nemožná, protože to nelze dost dobře dělat, pokud Rossum mění vše pod rukama.

Z toho důvodů taky je Python spíše slepovanými kousky zdrojáků v C, jinak by rychlost byla prachmizerná.

[l4m4]

He, ta prachmizerná rychlost se překvapivě zlepší použtím PyPy, které není poslepováno z kousků C...

[Miloslav Ponkrác]

Takže pythonovské knihovny psané v C, kterých je většina i třetích stran samozřejmě v C běžet nebude.

Pypy jsem nezkoušel, neboť Python jsem okamžitě pustil k vodě jakmile jsem zjistil, že Rossum hodlá nekompatibilně změnit syntaxi po 17 letech jazyka bez vážného důvodu.

Nicméně PHP jde přímo zkompilovat do C++ pomocí kompilátoru přímo z facebooku.

Kompilace produkuje vždy rychlejší výsledky, než zvládne JIT (přes všechny teoretické kecy o JIT produkované především javisty, kteří nezvratně pomocí mnoha nezfalšovaných testů dokázali, že Java běží rychleji, než C a dokonce i rychleji,než stroják a rychleji, než je rychlost světla.)

[JoHnY2]

Ono to obecne neni ruzovy. PHP stagnuje uz leta a zacina mu ujizdet vlak. Python je rozstipnutej a asi uz tak zustane. Ruby je hroznej slepenec a tak cool jak se zda. Perl 5 obrusta mechem a podle me je to neprehledna bestie (osobni nazor, proste mi nesedi). Perl 6 ma uzasnou specifikaci, ale bude production ready tak pro moje vnoucata.

Ale to docela odbihame. Me spis zajimalo jak velkej rozdil bude v req/s u Apache+PHP s nejakou slozitejsi aplikaci (Hello world v Zendu/Symfony ) kdyz, se pouzije GCC a EKOPath. Zajimavy by taky bylo jestli ma pouziti EKOPath vetsi dopad na PHP, ktery neuklada bytecode nebo Python, kterej jo.

PS: V konkurenci podobnejch jazyku bych to s Pythonem nevidel tak cerne. Navic cekam, ze to s nama bude 2ka na veky

[Miloslav Ponkrác]

„Ono to obecne neni ruzovy. PHP stagnuje uz leta a zacina mu ujizdet vlak. Python je rozstipnutej a asi uz tak zustane. Ruby je hroznej slepenec a tak cool jak se zda. Perl 5 obrusta mechem a podle me je to neprehledna bestie (osobni nazor, proste mi nesedi). Perl 6 ma uzasnou specifikaci, ale bude production ready tak pro moje vnoucata.“

A všechno co píšete má jednoho jmenovatele: Experiment, že zpětná kompatibilita je zbytečnost a přežitek.

Mnoho lidí po experimentech s rušením zpětné kompatibility prostě přešlo na prostředí, kde staromódně zpětnou kompatibilitu dodržují.

PHP udělalo dvě nekompatibility – mezi PHP 4 a PHP 5, z čehož vnizklo 2 roky trablů, kdy už nevěděli co dělat, aby autory donutili opoustit PHP 4. A protože jsou autoři PHP masochisti a mají rádi pocit zmarněné práce, tak teď je pro velký úspěch nová verze PHP 5.3, která leccos mění. A historie se opakuje.

Nicméně Python a Perl jsou drsňáci miliónkrát větší – a oběma jazykům to postupně zlomí vaz a bude to jedině dobře. Svět potřebuje odstrašující příklady, jak se věc dělat nemají – a že zpětná kompatibilita je nutnou podmínkou serióznosti i životaschopnosti jazyka.

Problém PHP není ani tak ve zpětné nekompatibilitě, protože ona zase není nijak velká na rozdíl od Pythonu a Perlu. Problém PHP je, že autoři PHP záměrně zkriplili jazyk a prostředí, aby mohli zbytek prodávat.

PHP je jediný jazyk, kde ve standardu není debugger, nebo třeba ukládání zkompilovaného byte kódu. Nebo nemá ždné stanadardní IDE aspoň prosťoučké. To všechno proto, aby to autoři mohli prodávat separátně.

PHP stagnuje, protože vylepšní PHP by konkurovalo s tím, co prodávali komerčně a tak na zlepšení PHP nemají zájem.

Bohužel PHP není definováno normou, ale jeho implementací, takže není možné se nasrat, udělat fork a autorům poslat mrtvou krysu, či jak to mafie dělá.

Proto pro úspěšný a rozvíjející se jazyk je třeba ctít zpětnou kompatibilitu a mít dobře napsaný standard v elektronické podobě jako dokument.

Všechny stálice jazyků: C, C++, Ada, Fortran, LISP, Java, to splňují.

„Ale to docela odbihame. Me spis zajimalo jak velkej rozdil bude v req/s u Apache+PHP s nejakou slozitejsi aplikaci (Hello world v Zendu/Symfony ) kdyz, se pouzije GCC a EKOPath. Zajimavy by taky bylo jestli ma pouziti EKOPath vetsi dopad na PHP, ktery neuklada bytecode nebo Python, kterej jo.“

Porovnejte na Windows rychlost Apache/PHP kompilovaným Microsoftím/Intelím kompilátorem a gcc – bude to naznačovat trend. Základní otázka je, jestli rychlost binárky bude mít nějak výraznější vliv vzhledem k rychlosti disku. Řekl bych, že dobře přepsaný alokátor paměti u Apache bude mít větší vliv na rychlost, než překlad lepšm kompilátorem. I když, gcc je děs v neoptimalizovanosti kódu, takže jeden nikdy neví.

„V konkurenci podobnejch jazyku bych to s Pythonem nevidel tak cerne. Navic cekam, ze to s nama bude 2ka na veky“

Já se vsadím, že bude černější budoucnost Pythonu,než optimisticky popisujete.

Ale co je na 100%, 2ka umře. A s ní do značné míry umře i Python.

[wtfjakovocode]

me prijde, zes minimalne perl v zivote nevidel. nebo ti zpetna kompatibilita do roku 1994 pripada malo?

[Miloslav Ponkrác]

Já to zkrátím: Z trojice PHP, Python, Perl sázím, že přežije jedině PHP.

Pro Python bude kritický rok 2013. Roku 2015 umře fakticky zcela.

Dále bych sázel na přežití Ruby, i když tu nebylo zmíněno.

Z modernějších jazyků bych sázel časem na stagnaci celého .NET prostředí, ale výrazně později.

[stativ]

Já to zkrátím ještě víc: seš mimo. Otázka byla rozdíl v rychlosti při použití EKOPath.

[okbob]

Zrovna takhle jste sazel na umreni PostgreSQL - tusim, ze to bylo pred 3-4 roky a zatim tu je a v lepsi kondici nez pred 4 roky.

Z Vami zminenych jazyku neumre zadny - je v nich napsano nadkriticke mnozstvi kodu - PHP zvlada hromada mladasu, Perl zase hromada starochu, kteri se nebudou ucit nic noveho - s nima tu bude Perl jeste 20 let - navic neexistuje nic podobneho CPANu (rozsahem). A Python je jeden z nejoblibenejsich jazyku pro vedu/vyzkum. Samozrejme, ze se bude menit popularita - urcite se objevi nove super jazyky, kazda generace se vymezuje nejak proti predchozi generaci, - ale ty budou mit problem si najit svou niku.

[stativ]

No, někde na fóru Phoronixu jsem zahlédl komentář, že Python zkompilovaný pomocí EKOPath je pomalejší než Python zkompilovaný pomocí GCC.

[stativ]

Mimochodem, zkusil jsem si tscp benchmark abych viděl, jaké jsou rozdíly mezi kompilátory. tscp jsem zvolil proto, protože na phoronixu v něm byl největší rozdíl. Výsledky jsou velmi zajímavé.

Testovací sestava – core i7 920, 12GB RAM, Arch Linux 64 bit.

Testované kompilátory (protože výstup --version je příliš dlouhý, píšu jen verze balíčků):

• gcc 4.6.0-6
• clang 2.9-5
• intel ze Studio XE 2011, update2
• path64-boostrapped-git 20110617-1

A teď výsledky:

• gcc

  Nodes: 550778
  Best time: 792 ms
  Nodes per second: 695426 (Score: 2.860)

• clang

  Nodes: 550778
  Best time: 889 ms
  Nodes per second: 619547 (Score: 2.548)

• intel

  Nodes: 550778
  Best time: 868 ms
  Nodes per second: 634536 (Score: 2.609)

• path64

  Nodes: 550778
  Best time: 800 ms
  Nodes per second: 688472 (Score: 2.831)

Jak je vidět, na phoronixu mají zřejmě rozbité gcc.

[Bedňa]

Jak je ľahké sa triafať do druhého že má niečo rozbité.

[stativ]

Vždyť jo

[Bedňa]

Osobne som to neskúšal, ale nechce sa mi veriť, že by niekto zaplatil toľko ako za dovolenku na Kube, aby získal to čo môže mať zadarmo