Tesztelők kerestetnek: már lefordul az OpenBSD/i386 -current kernel pcc-vel

OpenBSD

A BSD Fund - amely támogatja Anders Magnusson pcc erőfeszítéseit (1, 2, 3, 4, 5) - bejelentette, hogy a pcc mostantól képes olyan OpenBSD/i386 -current kernelt fordítani, amely be tud bootolni és az amd64 támogatás is hamarosan érkezik. További részletek itt.

( vargad | 2009. 12. 29., k – 14:20 )

Lesz itt végre egy kis verseny. Szerintem azért még mindig évekkel lehet lemaradva a gcc-től.

( bervi | 2009. 12. 29., k – 15:28 )

ez csodálatos, de ilyen hír volt már ~1,5 éve is.

másrészt az még szívmelengetőbb, hogy még a bsd-sek között sincs konszenzus, mert a freebsd meg az llvm&clang-ot nyomatja.
szerintem.

:)
Mas ok egyenlore nem latszik. Bar en szurkolok az llvm -nek :) De sajnos a testekben alul maradt, jelenleg nincs ertelme hasznalni produktiv kornyezetben, mint altalanos C forgato. Tech demonak elemenek a JIT -es kernelek is:)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Clang egy frontend. llvm -nek van gcc frontendje amivel lehet c++ is tolni.
Ami miatt szamomra erdekesnek tunik az llvm az optimalizalsi/profiling lehetosegei, amiken meg van mit dolgozni.
Tovabba GPU -val valo egyutt dolgozas is erdekes.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Milyen tesztekben maradt alul, miben, és mennyire? :)
A gcc itt van már egy ideje a clang/llvm pedig még csak most kezd lendületet kapni.

Hasraütéssel kb. azt tippelném, hogy a clang kb. annyival "rosszabb" a gcc-nél, mint amennyivel az icc "jobb" a gcc-nél, ez esetben viszont kijelenthetjük, hogy jelenleg nincs értelme a gcc-t használni produktív környezetben?

suckIT szopás minden nap! Beindult az optimalizáció az Oracle-nél

Ez a teszt tunik a legujabbnak:
http://www.phoronix.com/forums/showthread.php?t=18900&page=3
(Mas tesztek sem hoztak ki az ellenkezojet)

Sajat meresek sem mondanak mast, bar kisebbnek tunek a kulombsegek.

clang egy frontend az optimalizalashoz nincs tul sok koze. AFAIK.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

nekem is gyanús volt, de aztán néztem a csomagokat hozzá, és az is van belőle. vagy a csomag csak simán a ports buildje? de akkor mi ez a másik, amit linkelsz? ezt az én linuxos agyam nem érti :)

de akkor lehet, hogy mégis jól emlékszem, hogy a bsd-sek nem fognak gpl3-as gcc-re váltani (akármelyik verzió legyen is az).
szerintem.

Ja, linuxos aggyal tényleg nehéz. A FreeBSD-ben van egy alap rendszer, amit egy make worlddel tudsz fordítani. Ez egy kész valami, elég sokmindennel (pld. gcc-vel is).

Erre jönnek a portok, amik a /usr/local-ba települnek, és így élesen elválnak az alaprendszertől. Amit te nézel, az a gcc portnak a bináris manifesztációja, amit te is kapnál, ha make package-dzsel lefordítanád.

suckIT szopás minden nap! Beindult az optimalizáció az Oracle-nél

nem igazán értem (se a magyarázatot, se az analógiát). egyrészt a forrás ugyanúgy ki van adva, másrészt az alaprendszert is én rakom fel, illetve a ports-ot is a freebsd terjeszti. az meg végképp nem világos, hogy hogy jön képve a gplv3.

nálam ennek olyan szaga van, hogy a gplv3 még kevésbé "bsd-sebb", úgyhogy nem lesz az alaprendszerben gplv3, mert csak.
szerintem.

jó, a másik ok meg az, hogy bloated. csak az a baj, hogy valamiben vagy kevés a fícsör, vagy bloated. lásd mozilla vs. firefox. mire az llvm/clang vagy a pcc eljut a gcc tudásszintjére (ha eljut), gyanítom, hogy nem lesz klasszisokkal kevésbé bloated egyik se.

az meg, hogy lassabb, nem tudom... mennyivel? 10%-kal? 50-nel? szintén gyanítom, hogy nem olyan egetrengető a különbség, de nyilvánvaló, hogy van, kevésbé népszerű rendszer, nem foglalkoznak vele annyit.
szerintem.

Amugy egy nagyon hulye kerdes (tenyleg nem olvastam utana de most mar erdekel):

A ./configure lepest nem lehetne meggyorsitani?... Tudom mit csinal, de amit csinal, azt nagyon lassan teszi. A programok telepitesebol ez veszi el az ido 50% -at ha nem tobbet egy modern gepen ha tobb maggal forgatok.

Atter a projekt autotools -rol mondjuk sconsra vagy cmake -re az lehet megoldas :)

Egyebkent van confcache: http://gentoo.linuxhowtos.org/TipsTricks/confcache.htm, de problemas ugyhogy mar gentoo huszarok sem toljak.
Egyebkent pl. a portage kepes tobb csomagot forditani parhuzamosan.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Szultetett mas, irtam is.

autotools tipikus tul tervezett, az idok soran mutalodo szoftware egyutes, szinte entrspajz grade.
Arra lett kitalalva, hogy egy POSIX shell segitesegevel es az akkor letezo dolgokkal _MINDEN_ (majdnem 1000) platformon "egyszeruen" konfiguralhato legyen a forditas.
Add egy egyseges feluletet minden forditashoz. Bar lehet, hogy neked mondjuk az ebuild az egyseges felulet, de a portage -ben is sok tool igazodik hozza, az n+1 autotool-os szoftvernel sem kell sokkal maskep eljarni ha le akarod forditani.
Az reszlet kerdes, hogy ott ahol gyakran hasznaljak, lehetne egyszerubben is megoldani.

Gyanitom amikor kitalaltak meg sehol sem volt, libtool vagy pkg-config.

Ha a forditas reszekent, autoreconf -is tol az ember, akkor talan a sok izKenyerPirito ertekre konstansul be lehetne iratni a valaszt ./configure scriptbe, lecserelve a most behelyetesitett isKenyerPiritokat, vagy egyetlen nativ programot hivni ami gyorsabban megmondja mi a helyzet.

Ha megismered rajosz, hogy van az egeszben logika, van koncepcioja, es meg jo is valahol. Es tenyleg jo, ha az 1001. platformon kell hasznalni. De sajnos sok energiat igenyel a megtanulasa, es szokasos vegeredmeny egy lassu isKenyerPirito shell script halmaz.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"konszenzus"

Jujjj. :-/

Az Antallék idején találta ki valaki ezt az eszetlen kifejezést, mivel az egyetértés szavunk nem eléggé uras és túlságosan is jól érthető. Már ne haragudj, de értelmes embernek miért kell ilyen szót használnia? (A politikusok nagy része nem tartozik ide.)