GCC 4.2.0

Szerszám

Mark Mitchell bejelentette a GNU Compiler Collection 4.2.0-s verzióját. A bejelentésben az olvasható, hogy a 4.2.0-s verzió egy nagyobb kiadás, amelyben olyan szolgáltatások találhatók, amelyek a 4.1-ben vagy korábbi kiadásokban nem. A változásokról, új szolgáltatásokról és a javított hibákról bővebben a GCC 4.2 Release Series Changes, New Features, and Fixes dokumentum értekezik. A cucc letölthető a tükörszerverekről.

( gUHU | 2007. 05. 16., sze – 09:24 )

wazzeeee....
most forgattam újra minden rendszeremet, hamarosan megint kell :)

kíváncsi vagyok mennyiben hoz változást.

( yoursoft | 2007. 05. 16., sze – 09:52 )

Nem vagyok valami nagy c/Linux guru, de úgy rémlik valami olyasfélét is terveztek régebben, hogy ne töltődjenek be duplán liblary-k a memóriába.
Nem tudom már hol olvastam, de valahogy úgy írták, hogy az akkori Linux úgy használta a memóriát, hogy ha már volt bent a memóriában egy adott lib, attól függetlenül újra be töltötte, ha egy másik progi hivatkozott rá. Ennek köszönhető, hogy Linux alatt lassabban indulnak el a programok, mivel minden progi indításkor berántja az összes hivatkozott lib-et függetlenül attól, hogy azt már esetleg más használja. Ráadásul kevesebb memóriát is enne a Linux.
Ezt állítólag valamelyik gcc verzióban mint újdonság javították volna. Ugyan nem tudom mi köze van a gcc-nek az oprendszer szintű funkciókhoz, de hát ki tudja :-)

Lehet, hogy nagy baromságként fogalmaztam meg a dolgokat, de majd az okosak kiigazítják, ha kell. :-)

Na mindegy, ez nem tudjátok megvalósult már vagy még nem valamelyik gcc verzióban?

Pont ebben jok az .so file-ok.. legalabbis a statikus .a-hoz kepest.
Az elobbi a shared object, dinamikusan betoltheto, es egyszerre tobb program hasznalja ugyanazt a kodot a fizikaimemoriaban (csak persze mindegyiknek masutt van a virtualis cimtartomanyaban).
Kb 7-8 eve hasznalok Linuxot, es akkor mar emlekeim szerint igy mukodott..
Ha nem hiszed, a /lib-ben es a /usr/lib-ben megtalalod..
---------------------
int iPhone,iMac,iPod; // Apple using Hungarian notation :)

> Nem vagyok valami nagy c/Linux guru

Látszik.

Nem tudom, hol olvastad, de vagy bődületes baromságot olvastál, vagy félreértetted.

A shared object (olyan, mint a dll windows alatt) több program által is használható rutinkönyvtár. A programozó döntése, hogy melyiket használja.

A gcc tud shared objectet is, és statikus objectet is kezelni. Időtlen idők óta. Én 11 éve használtam először gcc-t Linuxon, és természetesen tudta. Bizonyára jóval korábban is, mert fel se tételeztem, hogy ne tudná.

G

Ok. Tévedtem. Vagy az is tévedett akinek a cikkét olvastam és ő csak a statikus lib-eket ismerte.

Akkor máshogy kérdezem, és lehet, hogy eljutunk így valami értelmeshez is:
Van valami magyarázatotok rá miért töltődnek be Linux alatt a progik lassabban, mint pl. ugyanazon a gépen a WinXp-s port XP alatt?

A prelinket már használtam régebben, egy picit gyorsult, de még mindig gyorsabban indultak ugyanazok a progik XP alatt.
Bár ahogy most a hup wikin megnéztem, a KDE-ben ilyenkor illik kikapcsolni a "saját prelinkjét" és azt nem csináltam meg, de az csak max. memóriafoglalásban jelentkezhetett.

( sz | 2007. 05. 16., sze – 16:05 )

Valaki meg tudná mondani, hogy .xpm-eket hogyan lehet warningok nélkül megetetni vele?

Nna, miután postoltam, egyből rájöttem:
-static char * foo_xpm[] = {
+static char const * foo_xpm[] = {

( tr3w v | 2007. 05. 16., sze – 18:31 )

Végre... Vártam már mint a messiást.
OpenMP-re fel!

Hamár eszembe jutott, egy kérdésem lenne azokhoz akik használtak már OpenMP-t:
Milyen overheadje van pl egy parallel for-nak?
Ilyenkor minden esetben új threadek jönnek létre, majd megszűnnek, vagy van valami optimalizáció/újrafelhasználás?
Egyáltalán nagyságrendileg mennyi órajel egy thread indítása?

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o