Ulrich Drepper eltávolította az ia64 támogatást a glibc-ből

 ( trey | 2012. január 8., vasárnap - 13:21 )

Ulrich Drepper karácsonykor egy levelet küldött a libc-hacker levelezési listára, amelyben gyakorlatilag közölte, hogy amint megindul a glibc 2.16-os verziójának fejlesztése, eltávolítja az ia64 (Intel Itanium, nem keverendő az x86_64-gyel) támogatást a fő forrásfából és áthelyezi a ports-ba. Ulrich azzal magyarázta a lépést, hogy úgy hiszi, mindenki egyetért abban, hogy az Itanium halott. Hat nappal ezelőtt a 2.16 fejlesztése megkezdődött. Ulrich pedig ígéretéhez híven nekiállt az ia64 támogatás eltávolításának.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Nem vagyok nagy tudor ezen a téren de:
Ez minimális gyorsulással is jár vagy csak kód tisztulást eredményez?
Milyen egyéb pozitívum származik ebből?

Hát ez csak egy libc. Az esetek döntő többségében az ember igyekszik elkerülni az odahívásokat. Valszeg a gyorsulás minimális lesz ha lesz egyáltalán.

Itt a hír inkább az, hogy adtak egy kokit meg egy sallert a Intelnek és HP-nek.

--
GPLv3-as hozzászólás.

Értem, tehát ez a hír inkább gazdasági, mint informatikai:)

El is felejtettem megkérdezni: tudod te, hogy mire jó a libc? :)

----------------
Lvl86 Troll

azért kíváncsi vagyok, hogyan próbálod elkerülni az odahívásokat?

Mindent statikusan fordit uClibc-vel. :)

--
There are free things in life i'll never understand
Spelling and counting

Egy profiler kiválóan megmutatja neked melyik hívásokat érdemes elkerülni vagy írni helyette egy optimalizáltat az adott feladathoz.

--
GPLv3-as hozzászólás.

Gondolom te az esetek döntő többségében írsz saját sprintf-et, meg fopen-t.

Hát most pont kiválasztottál 2 olyan függvényt amire pont overheadet szoktam tenni (tehát inkább lassítom). :D

De igen, a string függvények elég jól kandidálnak a feladat specifikus optimalizálandó függvények csoportjába. ^^

--
GPLv3-as hozzászólás.

jo, de a string fvg-k durvan az 1%-t teszik ki a glibc-nek:)
Viszont a maradek fvg-nek a 75%-a meg olyan, amit az ember nem irna ujra maganak, hacsak nem mazoista.

Ezért is írtam a parentbe a string függvényeket és nem az egész libc-t, Mr Cpt. Obvious.

A lényegi posztom: http://hup.hu/cikkek/20120108/ulrich_drepper_eltavolitotta_az_ia64_tamogatast_a_glibc-bol#comment-1401745

Ha már egyszer visszalinkelték ezt a topicot, gondoltam tisztázom már ezt. :P

--
GPLv3-as hozzászólás.

nem gond hogy a string fvg-ket en irtam, nem te? Te az egesz glibc-t kerulod!;>
Sajnalom hogy ennyi idod van komment irasra, talan irhatnal egy ket uj printf-et, blogolj oda teszteles keppen!;)

> De igen, a string függvények elég jól kandidálnak a feladat specifikus optimalizálandó függvények csoportjába. ^^

http://hup.hu/cikkek/20120108/ulrich_drepper_eltavolitotta_az_ia64_tamogatast_a_glibc-bol#comment-1402040

Ez az én parentem a te stringes posztodhoz. Tehát én írtam. És soha ne sajnáld.

--
GPLv3-as hozzászólás.

jah tenyleg, nem en irtam, de nem is te vetetted fel

Ugye, ugye...

--
GPLv3-as hozzászólás.

most tenyleg a sajat hulyeseged irod ala?

Milyen hülyeséget?

--
GPLv3-as hozzászólás.

/o\ inkább ne folytassuk

Te kezdted.

--
GPLv3-as hozzászólás.

Ok, egyikotoknek sincs igaza, es mindkettotoknek igaza van. Ennek a szalnak mindenesetre legyen vege.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nézd az eredeti posztom tényleg könnyen félre érthető volt, ezt elismerem. Viszont egy későbbi posztomba sztem tisztáztam, hogy mire gondoltam.

Eredeti poszt: http://hup.hu/cikkek/20120108/ulrich_drepper_eltavolitotta_az_ia64_tamogatast_a_glibc-bol#comment-1401477

És a javító posztom: http://hup.hu/cikkek/20120108/ulrich_drepper_eltavolitotta_az_ia64_tamogatast_a_glibc-bol#comment-1401745

Majd megemlítésre kerültek a string fgv-ek: http://hup.hu/cikkek/20120108/ulrich_drepper_eltavolitotta_az_ia64_tamogatast_a_glibc-bol#comment-1402040

Egyébként volt már alkalmam olyan projektben részt venni ahol feladat specifikus string függvényeket kellett írni a számottevő gyorsulás érdekében. (Majd ha még eszembe jut másik eset is, azt is megosztom ha kell.)

--
GPLv3-as hozzászólás.

subscribe

Semmi extra, kukáztak egy halott arch támogatását. Gyakorlatilag töröltek egy valagnyi fájlt, mást még nagyon nem csináltak. Ezek viszont csak IA64-es glibc-be fordultak be, semmi egyebet nem érintett.

Nem értem, miért kellene, hogy bármi kapcsolata legyen más archokkal :)

----------------
Lvl86 Troll

Kivéve az Intelt :-) (meg persze a HP-t.)

Véletlenül került a hír a Progeny Linux kategóriába?
Vagy van valami köze a Progeny-hez?

szoval igy akar a red hat tisztessegtelen elonyt szerezni a hp-val szemben...

--
NetBSD - Simplicity is prerequisite for reliability

> szoval igy akar a red hat tisztessegtelen elonyt szerezni a hp-val szemben...

Úgy érted, hogy: a Red Hat, mint hardver gyártó; a HP, mint linux disztribútorral szemben?

szoval igy akar a red hat tisztessegtelen elonyt szerezni a hp-val szemben...

Hogy mi?

Ulrich Drepper a Goldman Sachs-nel dolgozik, szoval nem nyert.

nah akkor le vagyok maradva, mea culpa
viszont drepperrol mindenki tudja, hogy csak a paycheck-je erdekli, szoval kinek volt az erdeke? :p

--
NetBSD - Simplicity is prerequisite for reliability

drepperrol mindenki tudja, hogy csak a paycheck-je erdekli, szoval kinek volt az erdeke? :p

Még mindig nem értem. Vegyül pl. a RHEL-t. Az a döntés, hogy a RHEL-6 nem fogja támogatni az IA64-et (valamint az, hogy a RHEL-5 igen), sokkal korábban meghozatott, mint Drepper idei karácsonya. Vagyis az, hogy Drepper most a 2.16-ból kiirtja az IA64 támogatást, nagyjából édesmindegy kell legyen a HP-nek. Csak akkor számítana, ha valamelyik hivatalosan támogatott disztribúció Drepper lépése miatt dobná az IA64-et. Nincs ok-okozati összefüggés glibc és disztrók között. Az IA64-re visszaesett a kereslet, ezt követik (egymástól függetlenül) különféle gyártók.

http://en.wikipedia.org/wiki/Itanium#Software_support

However, Microsoft announced in 2010 that Windows Server 2008 R2 will be the last version of Windows Server to support the Itanium, and that it would also discontinue development of the Itanium versions of Visual Studio and SQL Server.[12] Likewise, Red Hat Enterprise Linux 5 was the last Itanium edition of Red Hat Enterprise Linux[13] and Canonical's Ubuntu 10.04 LTS was the last supported Ubuntu release on Itanium.[58] HP will not be supporting or certifying Linux on Itanium 9300 (Tukwila) servers.[59]

Oracle Corporation announced in March 2011 that it would drop development of application software for Itanium platforms, with the explanation that "Intel management made it clear that their strategic focus is on their x86 microprocessor and that Itanium was nearing the end of its life."[60]

(Magánvélemény.)

Az pedig 100%-ig rendben van, hogy Dreppert csak a paycheck-je érdekli. Feltehetően iszonyat munka a glibc karbantartása. A kód licensze adott, Drepper meg arra fordítja az idejét, amire akarja / amiért megfizetik. Ha nem tetszik, amerre a glibc-t viszi, lehet neki pénzt adni, vagy lehet forkolni a glibc-t. (Ahogy meg is történt pl. az eglibc-vel.)

Soha nem értettem a szájhabzást Drepperrel kapcsolatban. Eddig egy glibc hibát jelentettem (getconf probléma), villámgyorsan megfixálta. Az strlcpy() témában szimplán igaza van. Szabad szoftveren dolgozni nem jelenti azt, hogy a felhasználók dirigálnának neki. És így tovább. Emellett rendkívül értékes szöveges anyagokat készített.

Kerdezz ra a ppc scenenel, h milyen remek munkat vegzett az altaluk bekuldott patchekkel kapcsolatban.

---
pontscho / fresh!mindworkz

Hmmm, erről nem tudtam. Mindenesetre nem tudok vele vitatkozni. Elszomorító.

Feltehetően iszonyat munka a glibc karbantartása.

Jah, kemény meló lehet a WONTFIX hibajegyek osztogatása a problémákra.

Hű, ez a posztod frissülhetett, mióta utolszor olvastam. Na, ráugrok még egyszer. Köszi :)

... Ez tényleg gáz. Visszagondolva, már legutóbb is azért nem kommenteltem a posztod alá, mert Drepper álláspontja itt nem védhető. A POSIX-ra való hivatkozással mondjuk nem értek egyet (a libc részét képezi a POSIX implementációnak, tehát belül azt csinál, amit akar (szerk.: legalábbis "összerakott", tanúsításra szánt kernel kíséretében, bár ennek megjelölésével Drepper szintén adós maradt)), ugyanakkor ha máshol nem is, ott mindenképpen megbukik a dolog, hogy egyszerűen nincs olyan kernel, amely garantálná az mprotect() sikerességét minden körülmények között: http://sourceware.org/bugzilla/show_bug.cgi?id=12492#c4

> nincs olyan kernel, amely garantálná az mprotect() sikerességét minden körülmények között

Talán ezért "int mprotect(...)", és nem "void mprotect(...)" ...

Majd jól leforkolja aztán jólessz!

--
http://neurogadget.com/

Az itánium halott?

Jó, hát törjék el a kezem, ha Itániumon glibc -t akarnék használni, de akkor is, hogy lehet már ilyet írni?:)

Szer: amúgy válaszként a HP álljon már le a Linux eröltetésével. Imho teljesen felesleges.

Nem tőle és nem most hangzott el először ez az állítás. Legutóbb ha jól emlékszem az Oracle tett ilyen kijelentést.

--
trey @ gépház

Ha jól emlékszem a Microsoft is felhagyott a támogatásával. Néhány architektúra meghalt az Itanium miatt, mert úgy gondolták hogy úgysem tudnának vele versenyezni.

lsd parisc :)
de akkor sem ertem, miert halott.

Kell legyen annak oka, hogy a HP eloszor PA-RISC -et majd Itaniumot rakott a gepeibe.
Trivialisabb lett volna egy HP-Ux for X86_64 release, de valahogy ez nem kovetkezett be.

Nyilvan gazdasagi az erdek pl. oracle oldalan. Minek tobb architekturara fejleszteni es optimalizalni, ha egyszer a piac jelentos resze x86.

Kell legyen annak oka, hogy a HP eloszor PA-RISC -et majd Itaniumot rakott a gepeibe.

Természetesen van oka: The architecture originated at Hewlett-Packard (HP), and was later jointly developed by HP and Intel. (wikipedia).

Bizonyára láttál már IA64 assembly-t; az egész brutális out-of-order execution-re, spekulációra, a pipeline megtöltve tartására van kihegyezve. A "sufficiently smart compiler" alá készült platformnak; a fordító feladata (mondjuk) C-ből előállítani azt az IA64 assembly-t, amely a processzor számára lehetővé teszi a maximális párhuzamosítást, spekulációt és így tovább. Sajnos ezeket a fordítókat azóta sem sikerült megírni (parafrázis Knuth-tól, lásd ismét a wikipedia-t és az onnan linkelt interjút). A gcc-nél pl. nem ritka, ha jól láttam, hogy a lényeget belerakja az insn bundle 0-s slot-jába, a másik két slot-ot meg kitölti nop.i-vel.

Az Intel C fordító nem tudom, milyen assembly-t generál, de ha tökéletesen kihasználná a processzor képességeit, valószínűleg nem léptek volna ennyien olajra.

Trivialisabb lett volna egy HP-Ux for X86_64 release, de valahogy ez nem kovetkezett be.

Nem, mert ha már volt processzor, akkor bizonyára használni kellett ("majd idővel lesz jobb fordítónk is"), valamint az x86_64 is kétségkívül egy fostalicska (nem (csak) az utasításkészlet, hanem az egész architektúra, úgy, ahogy van).

Kösz az infót, ennyire (sajnos) eszembe sem jutott belemenni az Itánium életébe, de
a HP-Ux -et -felteszem- a HP ugy irta meg, hogy kihasználja a HW -t... akkor az Oracle miért nem azt használta.

nah, akkor n+1-edszerre, mitol fostaliga az x86_64? :)

--
NetBSD - Simplicity is prerequisite for reliability

Feltetelezem az x86_ resze miatt.

--
|8]

Ami betűszó az architektúra kapcsán eszedbe juthat, az mind toldott-foldott. Például van benne egy valag óra (tsc hpet pit pmtimer rtc), részlegesen átfedő felhasználási területekkel. A PCI konfiguráció szét van szórva minimum PCI config space-be meg ACPI táblákba. Ötvenféle cache van. Az MTRR inicializació (rendezvous) többmagos gépen külön diplomát igényel. Nehéz eldönteni, hogy az UEFI kínosabb-e, vagy a BIOS. MSI, MSI-X. Szegmentáció. És így tovább.

Természetesen ezek legtöbbjével csak igen felületesen találkozom, de ilyenkor mindig előkerülnek a manual-ok, és egyre jobban gúvad a szemem, hogy hogyan bírtak ilyet összehozni. Semmi sincs, ami önálló, szeparált lenne; minden mindenbe belelóg. Addig persze semmi baj nincs velük, amíg nincs hiba :)

Nem tudom, hogyan lehetett volna szebben-jobban megcsinálni (ráadásul a piacra koncentrálva), de ettől még hajmeresztő.

Na igen. En ugyan csak messzirol szagolgatom ezeket, de azert elborzaszto latni, hogy a hackintoshnal is mit ossze kinlodnak a fejlesztok. Es egyaltalan nem amiatt, mert meg kell kerulni az apple vedelmeit, az bakfitty. Ilyen hardver, olyan driver, most acpi-t kell hekkelni, most ki kell kapcsolni a BIOS-ban a legacy USB tamogatast, mert nem bootol tole a gep, CPU-t kell konfiguralni, mert hulyesegek jonnek ki belole... doh. De lehet, hogy mivel en nem ertek hozza, ezert csak a problemakat latom.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

ez a legacy atka, mondjuk az uefi nekem mindenkeppen pozitiv :-)

--
NetBSD - Simplicity is prerequisite for reliability

amúgy válaszként a HP álljon már le a Linux eröltetésével. Imho teljesen felesleges.

"HP is not planning to certify or support any Linux distribution on the new Integrity servers based on the Intel Itanium processor 9300 series."

http://h20341.www2.hp.com/integrity/w1/en/os/linux-on-integrity-overview.html

Mar nem tudom kovetni, ez most akkor a sima glibc, vagy az eglibc, vagy valami mas?
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

sima glibc