PCC: Újabb C fordító

Programozás

Anders Magnusson a NetBSD fejlesztői levelezőlistán közölte, hogy kedvtelésből az utóbbi években a pcc nevű C fordítón dolgozik. Két nap portolási munka után a NetBSD i386 felhasználói térben levő programokkal sikerrel járt, a gcc-hez képest 5-10-szeres sebességnövekedést tapasztalt.

Bár a forrásban már 6 különböző architektúra is szerepel, a mostani állapotában még csak i386-on használható. Az anyag már be is került a pkgsrc rendszerbe (pkgsrc/lang/pcc). A honlapja itt, bejelentés és párbeszéd a fejlesztővel a userlevel, toolchain, és a kernel listákon folyik.

( turul16 v | 2007. 09. 15., szo – 18:48 )

Mit tud a SIMD -röl?
Az 6x sebbeség gondolom a fordítási időre vontakozott, annyira csak nem optimalizál jól :)

Ugyanzt le tudja fordítani mint a gcc, akkor mindegy. Szerintem valami benchmark-file-t kellene beforgatni, gyorsabb e lassabb e ..... A C nyelv nagyon jó, csak valóban a fordító már akkorára hízott, hogy szerintem a fejlesztők 80%-a csak a maga által fejlesztett részekkal van tisztában, kicsomagolva több mint 200-mega. Ki a fene tudna ennyi txt-t fejben tartani.

heirloom-sh, mert "tiszta" UNIX kod, nem GNU es nem BSD


gcc -c -D_GNU_SOURCE

133.26s real 117.49s user 15.51s system

-rwxr-xr-x 1 root wheel 110535 Sep 13 13:17 sh

pcc -c -D_GNU_SOURCE

40.88s real 35.37s user 5.29s system

-rwxr-xr-x 1 root wheel 138874 Sep 13 13:14 sh

--
Bow down and admit defeat. | Old, weak and obsolete.

gcc -O0 ?

Test file
Nekem legbénább Amd64 (single chanel, 1.8Ghz 2800+, gcc-4.2.0)
gcc -O2

time make CFLAGS=-O2 >/dev/null 2>/dev/null
real 0m9.048s,user 0m6.243s,sys 0m0.807s
-rwxr-xr-x 1 turul users 118255 Sep 15 22:27 sh

time make CFLAGS=-O0 >/dev/null 2>/dev/null
real 0m4.202s ,user 0m2.560s, sys 0m0.723s
-rwxr-xr-x 1 turul users 139352 Sep 15 22:30 sh

Milyen vasad van ?
(Valami flash zabálja CPU -mat, de lényeen nem változtat)
(Amd64 bináris nagyobb)

gcc

time make

real 0m3.076s
user 0m2.290s
sys 0m0.630s

-rwxr-xr-x 1 oliver oliver 113167 2007-09-15 22:50 sh

--> 3150Mhz P4 (northwood)

gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

pcc-t meg lusta vagyok felrakni debianra

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.
debian 4.0 - linux-2.6.22.6-pancs1-wifi2 - 2.6.22.6 kernel madwifivel itt

mivel gentoo-s gcc-vel tolod és nem egy 486-osra optimalizált cuccal :P

debianossal ennyit lehet kisajtolni:

time make -j4 CC=gcc LDFLAGS="-m32" CFLAGS="-v -O0 -m32" >/dev/null 2>/dev/null

real 0m2.194s
user 0m3.570s
sys 0m0.630s

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.
debian 4.0 - linux-2.6.22.6-pancs1-wifi2 - 2.6.22.6 kernel madwifivel itt

Rájöttem, hogy csaltam :)
Amikor CC=gcc meg volt adva akkor használhatta ccachemet.
which gcc
/usr/lib/ccache/bin/gcc
which cc
/usr/bin/cc

(A default cc)

time make CC=cc LDFLAGS="-m32" CFLAGS="-O0 -m32" >/dev/null 2>/dev/null

real 0m3.085s
user 0m2.347s
sys 0m0.683s

:D

úgy, hogy azt -j4-el forgattam és a time a make idejét méri, -j4-el meg több szálon forgatok (4 szálon) mivel HT-s P4 igy gyorsabb :P

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.
debian 4.0 - linux-2.6.22.6-pancs1-wifi2 - 2.6.22.6 kernel madwifivel itt

Tehat csak gyorsabban fordit, en ugy veszem ki.

Én is. És közben 20%-kal nagyobb binárist csinál.
Ennek semmi értelme. Manapság az ember kivárja, hogy 4-5 órán keresztül készül a kernel...rpm-je, de elvárja, hogy a keletkezett kód olyan legyen, mintha ember írta volna assembly-ben.

ha tobb forditot is tudsz hasznalni, akkor elso sorban ezt nyered vele:

"About 80 files in the NetBSD code were changed to make it compile. Most were just gcc constructs/keywords that had to be changed to c99-style, some were plain
errors in the code that gcc ignores. I plan to check in these fixes."

--
Bow down and admit defeat. | Old, weak and obsolete.

Azert mondjuk programfejlesztes kozben: irok, forditok, tesztelek, javitok, forditok, tesztelek, _baromira_ szamit a forditasi ido.

Mondjuk ugy, hogy semmi mas nem szamit. Foleg nagyobb projekteknel sok sok percet/orat jelenthet ez.

Aztan ha megvan a hibatlan algoritmus, az osszes ostoba szintaktikai es szemantikai hibat az ember kidobalta, akkor lefordithatja masik forditoval, ami kicsi es gyors kodot keszit.

Nem veletlenul van altalaban ket kulonbozo modja a fejlesztesi verzio forditasanak es a release verzio forditasanak.

G

( bra | 2007. 09. 15., szo – 20:37 )

Oh, ne. Lassan annyi nyílt forrású C fordító lesz, mint Linux disztribúció. :)

Ez így igaz, főleg, ha a régit nem te írtad. Mondjuk egy szabad és használható C/C++ fordítónak nyilván sokan örülnének.
Érdekes, hogy ezt a látszólag kezdeti állapotban lévő dolgot már be is tolták az OpenBSD fába, míg a (gondolom) fejlettebb TenDRA irányába nem mutattak ekkora érdeklődést.

Csak beindul egyszer a GNU-s megoldások kiváltása ezen a téren is. ;)

( handler | 2007. 09. 15., szo – 22:48 )

FYI:

"TCCBOOT is a boot loader able to compile and boot a Linux kernel directly from its source code.

TCCBOOT is only 138 KB big (uncompressed code) and it can compile and run a typical Linux kernel in less than 15 seconds on a 2.4 GHz Pentium 4."

Ezt csak azert hiszem el, mert az a ficko irta, aki az ffmpeg-et, es ott mar elegge bizonyitott...

Ettol fuggetlenul nincs sok ertelme se a PCC-nek, se a TCC-nek, mert egy C forditonal nem az a lenyeg, hogy mennyi ido alatt forditja le, hanem hogy milyen a vegeredmeny. Ebben egyelore a gcc es az icc verseng, fej-fej mellett. Es ezek nem azert sok 10 megasak, mert valakinek szofosasa volt, hanem a kulonbozo optimalizaciok miatt nottek ekkorara, es ha esteleg ezeket beepitenek a pcc/tcc-be akkor azok is nagyok es lassuak lesznek.

A'rpi

intel procin az icc gyorsabb kódot képes generálni? és képes úgy generálni az icc a kódot, hogy kevesebb energiát egyen a gép (a gcc tudja arm-elf platformon, kár, hogy i386 és felfelé archon nem)?

---------
"Ha igazat mondasz azt végig unják, ha feldíszíted azt jól meg dugják"
szerény blogom -- új címen!

icc elvileg tud SIMD-t jól optimalizálni.

Mit értesz azon, hogy energi takarékosabb kód ?
-mthumb látok, azt akkor javasolják, ha program tár 16 vagy kisebb bus szélességen kapcsolódik. Általában jobb kódsürűséget eredményez. Energia takarékosság szempontjábol nem tudom. De Thumb -re gondolom az icc is tud forgatni.

A lényege az egésznek az, hogy valahogyan csökkenti az egész gép (főként a processzor) energiafogyasztását valahogyan. Az újabb telefonokra ezzel forgatják a szoftvert, és 50-100% üzemidőt nyertek vele, és ez komoly (az egyik tanszék kutatási területe ez a projekt, meg a gcc által generált kód javítása).

A GCC hogy áll a SIMD-vel?

---------
"Ha igazat mondasz azt végig unják, ha feldíszíted azt jól meg dugják"
szerény blogom -- új címen!


#include <stdio.h>
int main()
{
 float a[4];
 float b[4];
 scanf("%f,%f,%f,%f",a,a+1,a+2,a+3);
 scanf("%f,%f,%f,%f",b,b+1,b+2,b+3);
 __asm__ (
 	  "movaps 16(%rsp),%xmm0\n\t"
          "addps (%rsp),%xmm0\n\t"
	  "movaps %xmm0,(%rsp)\n\t"
          );
/*	  
 b[0]+=a[0];
 b[1]+=a[1];
 b[2]+=a[2];
 b[3]+=a[3];
 */
 printf("%f,%f,%f,%f",b[0],b[1],b[2],b[3]);
return 0;

}

Ha C rész marad benne: 


  40059f:       f3 0f 10 04 24          movss  (%rsp),%xmm0
  4005a4:       bf f8 06 40 00          mov    $0x4006f8,%edi   # ez most mindegy
  4005a9:       f3 0f 10 4c 24 04       movss  0x4(%rsp),%xmm1
  4005af:       f3 0f 58 44 24 10       addss  0x10(%rsp),%xmm0
  4005b5:       f3 0f 10 54 24 08       movss  0x8(%rsp),%xmm2
  4005bb:       f3 0f 58 4c 24 14       addss  0x14(%rsp),%xmm1
  4005c1:       f3 0f 10 5c 24 0c       movss  0xc(%rsp),%xmm3
  4005c7:       f3 0f 58 54 24 18       addss  0x18(%rsp),%xmm2
  4005cd:       f3 0f 58 5c 24 1c       addss  0x1c(%rsp),%xmm3
  4005d3:       b8 04 00 00 00          mov    $0x4,%eax         # ez most mindegy 
  4005d8:       f3 0f 11 04 24          movss  %xmm0,(%rsp)
  4005dd:       f3 0f 11 4c 24 04       movss  %xmm1,0x4(%rsp)
  4005e3:       f3 0f 11 54 24 08       movss  %xmm2,0x8(%rsp)
  4005e9:       f3 0f 11 5c 24 0c       movss  %xmm3,0xc(%rsp)

Ezt műveli a 3 sor helyett, szinte bármilyen parmétert adva gcc-nek nem lesz tömörebb. (4* annyi 3*4=12 utasítás)
Ugyan így szorzással..

Persze :)
A progalap nagyon nagy Dévényivel, az arch érdekes, dimaton jókat lehet aludni és értem, kalkulus meg vicces, mert együtt nem értünk semmit, de ha értenénk, akkor is megbukunk :)

---------
"Ha igazat mondasz azt végig unják, ha feldíszíted azt jól meg dugják"
szerény blogom -- új címen!

[OFF]
Kedvencem volt, amikor az elottem levo gyerek irja windows vistan, microsoft wordbe a kovetkezot:

ls - fajlokat listaz
...

Aztan amikor a top-rol volt szo, elovette a windows rendszerfigyelot, es megmutatta a mellette levo csajnak. Eleg meresz volt ez azok utan, hogy vistan ha filmet nezel lerohad a halozat, mert nem birja a megszakitasokat.

ahahah
[/OFF]

Az már régi ügy.

Azért használtam múlt időt, HTH (és nm is igazán értem, hogy miért releváns az, hogy mikor volt).

Vista -ban javították ?

Fogalmam sincs. Workaround elvileg van rá.

It doesn't matter if you like my song as long as you can hear me sing

ehhez képest nekem baghira theme-es kde-ben nyitva volt a kwrite, oda jegyzeteltem, meg az xterm, oda meg írtam; aztán elindítottam egy prímszámoló programot, mert fázott a kezem :)

---------
"Ha igazat mondasz azt végig unják, ha feldíszíted azt jól meg dugják"
szerény blogom -- új címen!

A progalap nagyon nagy Dévényivel, az arch érdekes, dimaton jókat lehet aludni és értem, kalkulus meg vicces...

Vákicsit!

Nem nyitnátok vmi. fórumtopikot, ahol ezeket az infókat up-to-date tartanátok, hogy mik is az aktuális témák? Nekem gyanús, abból, amit itt írtok, hogy Dévényi friss új technológiákról is beszél, amikhez időm se volt pl. hozzászagolni, és én Dévényihez még '98-99-ben jártam...

(PS.: Kalkulust felejtsétek el! Pontosabban tanuljátok meg... Ne attól a ..... Az lehetetlen. Elő pár matekkönyvet, mondjuk Pintér Lajos féle spec.matos középiskolás matek könyveket, meg a többit. Tudom Leindlerrel riogatnak titeket... Az matkusssoknak való, száraz, és uncsi...)

Vagy szerezzetek vmi. tökösebb EHÖK elnököt, aki az utilaput odaszögeli "minden Laci" fenekére, aki nem Szabó Laci! Mármint a borotvált! Ő jól el tudja magyarázni a Kalkulust, és meg is lehet érteni! Jegyzet átfutásával, 0 +tanulással, 5-ös lettem! Nem melléduma! ;-)

( wELDER v | 2007. 09. 17., h – 07:05 )

welder@dreamer ~/heirloom-sh-050706 $ make clean >/dev/null 2>/dev/null
welder@dreamer ~/heirloom-sh-050706 $ time make -j4 CC=gcc LDFLAGS="-m32" CFLAGS="-v -O0 -m32" >/dev/null 2>/dev/null

real 0m3.414s
user 0m2.939s
sys 0m0.465s

AMD Sempron 2200+ 256Mb RAM - Gentoo

( asch v | 2007. 09. 17., h – 08:36 )

A sokféleség mindenképpen jó dolog. Versenyt hoz, növeli a kompatibilitást egyszóval király. Kellett is BSD licenszű C fordító már. Így a BSD-sek örülhetnek és portolhatnak, én meg bármely termékünkbe tehetek egy C fordítót és terjeszthetem bármilyen zárt licensz mellett.

Régebbi postokban hőzöngtem, hogy a C/C++ nem igazán platformfüggetlen, egy új fordító ezen sokat segíthet. Csak az a kérdés, hogy tényleg ki fogják-e javítani a hibás kódokat, vagy beleteszik az új fordítóba a GCC compatibility layert inkább... Remélem az előbbi :-)

"Régebbi postokban hőzöngtem, hogy a C/C++ nem igazán platformfüggetlen, egy új fordító ezen sokat segíthet."
ezt én úgy értelmeztem, hogy azért nem platformfüggetlen a C/C++, mert nincs olyan fordító, amelyik fut a legtöbb platformon; de lehet én értettem félre

---------
"Ha igazat mondasz azt végig unják, ha feldíszíted azt jól meg dugják"
szerény blogom -- új címen!

( Zahy v | 2007. 09. 19., sze – 20:14 )

Hát FreeBSD-n bekerült ports-ba - kb 3x javították, de most már megy -, viszont bármitől ami signal.h -t include -ol, attól nagyon csúnyákat kezd mondani. Persze egy jó kis gcc-izm van a kérdéses helyen, azaz az, hogy mindent tud amit a GCC, attól messze van.