LinuxDNA – szybsze jądro z kompilatorem Intela
- Dodano: 2 marca 2009
- Wprowadził: mith
- Komentarze: 113
LinuxDNA to projekt, którego celem jest stworzenie i utrzymywanie źródeł jądra systemu Linux, kompatybilnych z kompilatorem Intela. Programiści właśnie odnotowali swój pierwszy duży sukces.
Sukcesem bowiem należy nazwać udane skompilowanie jądra w wersji 2.6.22. Nie chodzi jednak o przeprowadzenie kompilacji zakończonej bez błędów, ale uzyskanie w pełni kompatybilnego, działającego jądra, które może stać się podstawą do budowy systemu operacyjnego.
W tym momencie wielu czytelników zada sobie w duchu pytanie, czy jest w ogóle sens takich działań, skoro od lat bardzo dobrze spisuje się kompilator GCC. Autorzy projektu odpowiadają, że tak, gdyż może to dać spore zyski w wydajności, średnio 8% – 9%, ale dla niektórych fragmentów jądra nawet do 40%. ICC, czyli kompilator Intela, tworzy – jak zapewniają – lepiej zoptymalizowany kod wynikowy. Dzieje się tak, gdyż korzysta on z dwóch technik optymalizacji IPO (Inter Procedural Optimization) oraz PGO (Profile Guided Optimization).
IPO jest mechanizmem heurystycznym, gdy tymczasem PGO służy specjalnemu profilowaniu kodu. Działa to w taki sposób, że początkowo kompilator dodaje modyfikacje służące analizie wykorzystania kodu, a następnie dokonuje ponownej kompilacji, wprowadzając zmiany, mające na celu przyśpieszenie wykonywania plików wynikowych w najważniejszych, najczęstszych zastosowaniach. W ten sposób – spekulują twórcy projektu – można tworzyć profile jądra przeznaczone do konkretnych zadań – np. sprawdzające się lepiej jako podstawa do budowy systemu obliczeniowego lub też serwera sieciowego. Choć optymalizacja PGO jest dostępna również w GCC to kompilator Intela ma dawać lepsze wyniki.
W tej chwili istnieje jeszcze kilka problemów, które programiści projektu muszą rozwiązać, nim rozpoczną prace nad adaptacją nowszej wersji jądra. Głównym brakiem są problemy z wykorzystaniem sterowników udostępnianych jedynie w postaci binarnej. Twórcy LinuxDNA wierzą jednak, że uda im się szybko uporać z tą niedogodnością.
Głównymi programistami są:
- LuYi Cheng: Chiński haker jądra, który doprowadził je do stanu pełnej używalności.
- Feilong H: Pracownik Intela, który dostarczył wiedzy potrzebnej do napisania wymaganych łatek.
- Nieznany haker z Broadcom, który służył wiedzą i wsparciem technicznym.
- Claude Tyler McAdams: Haker oraz przedstawiciel projektu.
Tutaj znajduje się strona projektu.
Więcej informacji: http://www.linuxjournal.com/content/linu...c-compiler
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
113 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
Kiedy powstanie projekt wykorzystujący kompilator microsoftu?
wtedy gdy go założysz
Chcesz uruchamiać jądro Linuksa z poziomu Windowsa?
Przeciesz to juz bylo dawno. Nie pamietam nazwy ale normalnie w windows uruchamialo sie warste linuksa z jadrem umozliwiajac uruchamianie linuksowych aplikacji wprost w windows. Działało. Moze ktos pamieta nazwę?
Limo??
Cygwin?
colinux.
andlinux
Ale raczej nie chodzi o jądro…
ORLY? "andLinux uses coLinux as its core which is confusing for many people. coLinux is a port of the Linux kernel to Windows. " — http://andlinux.org/
jest też takie coś http://ring3k.org/
To byl Monkey Linux.
Nawet chyba kiedys go uzywalem wraz z Windows 95 lub 98.
Monkey Linux to była taka śmieszna dystrybucja na pięciu dyskietkach, którą można było rozpakować do katalogu na partycji FAT i stamtąd — po zamknięciu systemu Windows, albo z poziomu DOSa — uruchomić loaderem. Odpalał się normalny Linux ze środowiskiem graficznym.
Nie sądzę jednak, żeby o to chłopakom wyżej chodziło
ulteo zapewne o to chodzi, ale opcja instalacji w windows chyba została porzucona, bo coś nie mogę znaleźć na ich stronie. Ulteo Virtual Desktop w każdym bądź razie, ściągasz plik exe instalujesz i masz, pewnie to jak nazwa wskazuje Linux w wirtualnej maszynie, ale nie musisz o tym wiedzieć, by korzystać.
No nie wiem za co te minusy! Przecież MS robi taki dobry kompilator!
A dla tych co niewiedzą jak się nazywa linuks w windows:
>colinux
Microsoftowy kompilator nie dlatego nie skompiluje Linuksa, że jest jakiś ułomny (bo nie jest), ale dlatego, że Linux jest napisany z użyciem bardziej GNU C i nastawiony był od zawsze na wspieranie jedynie GCC i jego rozszerzeń. Fakt kompilacji Linuksa przez ICC świadczy o zGNUwieniu ICC.
Ale pewnie freeBSD da rade, co? ;p
@Apage: nie da rady, bo w przeciwieństwie do tego co pisze Rsh jest "ułomny" – znaczy się nie potrafi generować plików coff, a jedynie exe (kompilatory potrafiące więcej nie są udostępniane przez microsoft). Poza tym raczej nikt rozsądny by tego nie zrobił ponieważ kompilator z VS jest dużo wolniejszy od ICC, i wolniejszy od GCC (visual studia compiler przewagę miał w czasie gcc3, ale od tego czasu gcc przyspieszył znacznie i w serii 4 wyprzedził szybkością kod binarny generowany przez kompilator MS).
Ja bym nie stawiał tak bardzo na tą przewagę szybkości GCC nad MSVC. Jeszcze niedawno był flame na osnews jak to MS'owe kompilatory generują szybszego Firefoksa.
Co do ułomności to może w tym kontekście rzeczywiście, ale ogólnie to jest to dośc dobry kompilator – sam go nie używam, ale mam znajomych, którzy silnie go testują.
Chłopcze, nie wiesz to nie pisz, w tym momencie zachowałeś się gorzej niż trasz w najbardziej kontrowersyjnych wypowiedziach.
Kompilator optymalizujący (bo tak się nazywa kompilator używany przez Visuala) kompiluje do COFFa właśnie (konkretnie MS COFF – COFF zawierający dodatkowe), następnie COFFy są ew. linkowane do PE COFF-a (czyli execi, dll-ki itd.). Kompilator to cl.exe, linker – link.exe. Składnia wywołania klamotów jest podobna do gcc, icc czy inszego lcc. CL tak samo jak G++ bez podania przełącznika '-c' po skompilowaniu przekazanych plików prześle COFF-y do linkera, z nim, nadal tak samo jak G++, wyłącznie skompiluje COFF-y.
Zgadnij, po co w Menu Start Masz coś takiego jak Visual Studio 200x Command Prompt? Chociaż pewnie nigdy nie miałeś zainstalowanego Visuala – wiedziałbyś, że to konsola do ręcznej kompilacji, dokładnie takiej samej jak robi się to z kompilatorami GNU czy Intela.
Samego Visual Studio, jako IDE, też widać nie używałeś, kompilacja a budowa projektu to nie to samo – można skompilować konkretne pliki co COFF-ów bez linkowania binarki, i to bez posługiwania się linią poleceń.
Nie chciałbym Cie zmartwić, ale windowsowa wersja firefox'a z tego co wiem jest budowana z użyciem gcc ;p (a dokładniej mingw32), ale zaraz sprawdzę dokładniej. Przewaga odpalonego firefox'a pod wine jest optymalizacja samego wine – to tak jak przy testach ray tracerów, natywnie pod windowsem działa 3-4 razy woniej niż pod wine (wine swoją przewagę traci jak programy zaczynają używać gpu). Jakbyś przetestował szybkość firefox'a pod windowsem i pod linuxem natywnie to pod linuksem nieznacznie wygrywa… ale wine jakimś magicznym sposobem robi to samo szybciej (nie zagłębiałem się w to dokładniej).
@Rsh: co do oficjalnego build'a firefoxa niee miałem racji – jest zlinkowany msvcrt.dll – jednak szybsze są buildy z mingw32, ale i one pod wine dostają dodatkowych magicznych sił ;p.
Dzięki za oświecenie! Od lat już niczego nie kompilowałem i nie jestem w temacie. A ile to się człowiek nasłuchał o fullwypaśności kompilatorów komercyjnych zwłaszcza mikrosoft i badziewności gcc
@Apage: Nie sadze. Za to coraz bardziej daje rade kompilowac je LLVM-em.
@pijaczek: Podaj mi jeden konkretny przyklad programu, ktory skompilowany GCC jest szybszy niz kompilatorem Microsoftu. Tylko nie popelniaj tych samych bledow, co Thar kiedys, porownujac program kompilowany pod GCC ze wstawkami asemblerowymi (napisanymi tak, zeby byly nieprzenosne) z tym samym kodem kompilowanym LC, ale bez wstawek.
GCC _nadal_ ma kompletnie zwalona optymalizacje kodu. I nie oczekiwalbym poprawy – GCC jest po prostu zbyt duze i zbyt zabalaganione. Za kilka lat po prostu przejdzie sie na LLVM i zapomni o GCC.
trudno sie tu z traszem nie zgodzic.
jak sie zobaczy na wlasne oczy kod clang-llvm uruchomiony pod maszyna llvm-jit i dzialajacy do 15-20% szybciej od gcc4.3 -O3 to nieco szczena opada.
to ile mozna w gcc poprawic pokazuje kompilacja kodu posredniego llvm do natywnej binarki – ktora, jak nie trudno sie domyslic – wykonuje sie jeszcze szybciej niz z uzyciem maszyny jit osiagajac czasem niemal 50% zysku wzgledem gcc4.3.
W sumie to fakt JIT'a nie ma większego znaczenia. Koniec końców kod i tak ląduje w pamięci, a to jaki to będzie kod zależy tylko i wyłącznie od ustawionych przejść optymalizacji. (pomijając, że zazwyczaj JIT nie może mieć agresywnych optymalizacji ze względu na potrzebę szybkości skompilowania)
Lol? Co, gdzie, jak kiedy? Ja tobie podawałem program jako przykład tego, czemu nie jest pisany pod MSVC – bo kompilator wielu instrukcji nie wspiera. Ani słowa o asemblerze.
Skoro już, to napiszę, że asembler w x264 oczywiście JEST przenośny i nie ma nic wspólnego z używanym kompilatorem. Dokładnie odwrotnie, niż napisał trasz. Ale to mnie nie dziwi
Jeszcze jedno. Kolejny raz przejawiasz tendencję do przedstawiania faktów tak, jak ci wygodnie. Dlaczego clang za kilka lat miałby się wreszcie nadawać do użytku a gcc nie miałoby poprawić optymalizacji? Przecież w obydwu kierunkach – obsłudze kodu w clang i optymalizacji w gcc – prace ciągną się od lat. Na clangu kompiluje się coraz więcej kodu, gcc 4 dużo lepiej optymalizuje od poprzednich wersji. A, zapomniałem – clang to BSD-like, ta licencja w magiczny sposób czyni kod dziesięciokrotnie lepszym ;>
Twoja moherowa krucjata przeciw wszystkiemu co nie trafia w twoje licencyjne gusta jest znacznie bardziej intensywna niż pojawiające się od czasu do czasu komentarze paranoicznych antyfanów Apple. Próbowałeś to leczyć, czy może w devteamie FreeBSD prestiż jest proporcjonalny do umiejętności trollowania?
@LV: No właśnie MS COFF, a nie zwykły COFF (przekonałem się o tym jak napisałem mini jąderko i chciałem linkować – nie dało się i jedyne co w necie na ten temat w necie znalazłem to właśnie to, że kompilator MS nie potrafi zrobić zwykłych COFF i nie da się go użyć do kompilacji systemu – jeśli wiesz więcej na ten temat to byłbym wdzięczny jakbyś napisał).
@trash: Bardzo dużo – przykładami niech będą blender i lame (jasne nie na oficjalnym stabilnym gcc (mingw32) dla windowsa (bo on jest w wersji 3.4.5 z 2006 roku, ale buildy 4.3.3 – możesz zbudować sobie sam lub użyć wersji przygotowanych przez kogoś, np. http://www.tdragon.net/recentgcc/)). Niestety w kwestii szybkości kodu visual studio prawie stoi w miejscu od kilku wersji, a konkurencja nie śpi i gcc go ostatnio wyprzedziło.
@Thar: Trudno, zeby kompilator MSVC wspieral kompletnie niestandardowe i proprietarne rozszerzenia GCC. Rownie dobrze moznaby sie przyczepic, ze GCC nie wspiera rozszerzen MSVC. A x264 potrafi uzywac tylko tych pierwszych – przy kompilacji innymi kompilatorami pewne optymalizacje sa wylaczone, bo nikt nie zadal sobie trudu zapewnienia przenosnosci.
@Thar: Z dwoch powodow. Po pierwsze, LLVM ma lepsza strukture wewnetrzna. Po prostu latwiej zaimplementowac to, co jest potrzebne. Po drugie, LLVM ma coraz mocniejsze wsparcie komercyjne, a GCC na odwrot.
@pijaczek: A teraz przeczytaj jeszcze raz to, co napisalem o kodzie GCC-only, uzywajacym niestandardowych rozszerzen uznawanych GCC.
Ale mnie to ani nie obchodzi, ani nie mam na to wpływu – napisz to programistom. To oni używają niestandardowych rozszerzeń gcc, ergo najwyraźniej im odpowiadają/są wygodne/potrzebne. Trudno, żeby używali kompilatora który karze im wykonywać więcej pracy, gdy alternatywa jest wolnodostępna. ;>
Nie wiem, jaką strukturę wewnętrzną ma LLVM, ale to zdaje się jest jedynie backend? Clang dzieli z nim jakiekolwiek fragmenty kodu?
@trash: to były tylko przykłady. Nie wiem do końca jak to jest z lame, ale blender nie używa wstawek asm i też nie ma używa żadnych tricków/rozszerzeń gcc, a rendering buildów z gcc4 jest znacząco szybszy.
BTW. programy nie są gcc only, a visual jest "asm intel" only dlatego optymalizacje (np. z użyciem instrukcji procesora np sse…) pisane w notacji at&t na nim nie działa (a szkoda że nie tak jak gcc intel i at&t (at&t jest standardowo, a aby użyć notacji intela trzeba użyć ".intel_syntax noprefix" przed kodem i ".att_syntax noprefix" po kodzie w intelowskiej notacji)).
@trasz: co do "zapomni się o gcc" to coś tego nie widzę (mimo, że bardzo chciałbym aby LLVM się prężnie rozwijał), bo gcc ostatnio ruszył w kierunku optymalizacji, zaczyna się planować implementacje w nim openCL (co da dodatkowego kopa aplikacją, ale nie będzie kompatybilne z visualem więc różnica będzie jeszcze większa, pomiędzy aplikacjami kompilowanymi gcc vs visual), i co najważniejsze najszybciej adaptuje standard C++0x, na który z niecierpliwością czekają programiści.
@Thar: Ale w tym momencie twoj przyklad – w tym konkretnym przypadku x264 – jest bezuzyteczny, bo nie porownujesz wydajnosci tego samego kodu kompilowanego dwoma roznymi kompilatorami – porownujesz wydajnosc _roznego kodu_.
@pijaczek: Kiedy ostatni raz ktos probowal mi to udowodnic, tez twierdzil, ze nie ma zadnych nieprzenosnych wstawek. Wiec – sorry, nie uwierze dopoki nie obejrze.
A co do notacji AT&T – mozesz pokazac mi kawalek standardu, ktory mowi, ze ta notacja jest w jakis sposob standardowa?
@trasz: mój przykład _w ogóle_ nie odnosił się do wydajności, a do powodów używania gcc. Wymyśliłeś coś sobie a teraz powtarzasz z uporem maniaka. x264 nawet się pod msvc nie kompiluje.
@trasz: Nikt nie broni sprawdzić – aby zaoszczędzić Ci czasu sprawdź sam "render", czyli katalog "source/blender/render/" w źródłach.
Notacja AT&T obowiązuje na wszystkich platformach i tylko na x86 jest używana także notacja intela.
Ostatnio piszę pewien program, który stanowczo potrzebuje jak najszybszego generowanego kodu – generuje każdą kombinację znaków dla podanego charsetu i długości, dokleja do tego pierwsze 2 oraz 1 ostatni znak z md5 tej kombinacji, w notacji hex, następnie wyrzucaja na stdout [potem to zmienię na mmap
]
Z ciekawości [tworzyłem w VS] przetestowałem też GCC oraz ICC, oto wyniki: http://wklej.org/id/58834/
(4 znaki, charset a-z0-9; test był powtórzony wielokrotnie)
Flagi:
<code>
GCCF:=-Wall -O2 -I../pinky/ -funroll-loops
ICCF:=/fast -I../pinky/
MSCF:=/Ox /Oi /Ot /GL /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /FD /EHsc /Gy /arch:SSE2 /W3 /nologo /TP /errorReport:prompt
</code>
Do bani flagi gcc. Spróbuj te podane w komentarzach na LWN. Teraz nie masz nawet SSE (o ile to nie jest gcc na win64).
@puppy: Rozbawiłeś mnie ;p MSCF jest optymalizowany dobrze, a GCC jest dobrze spowalniany ;p
M.IN. Użyłeś optymalizacje poziomu 2, a nie 3, nie pozwoliłeś mu optymalizować sse2, a mscf tak (-msse2), użyłeś -funroll-loops który robi kod większy i często wolniejszy, nie użyłeś -fomit-frame-pointer (zależnie od hosta mogło akurat być automatycznie włączone z -O2).
Podsumowując poczytaj manual'a gcc na temat optymalizacji i wtedy rób testy ;p
Akurat loop unroll jest bardzo przydatny i przyspiesza kod – chyba że to w gcc się jakoś inaczej zachowuje, bo ogólnie się to stosuje przy optymalizacji – w msc i icc mam włączone. I fakt, po dodaniu -msse2 oraz -O3 i -fomit-frame-pointer (oraz loop unroll) szybkość wzrosła – generuje szybszy kod (przynajmniej w moim poor-man's benchmark) niż MSC, choć nadal jest w tyle za intelem. Jednak przy wywaleniu loop unrolling szybkość spada o całą sekundę i gcc nadal jest na ostatnim miejscu
Zatem podsumowując: w moim przypadku intel > gcc > msc. Procesor 32bit, 1,6 ghz, ht.
@puppy: nikt tu nie neguje, że intel z nich jest najszybszy, unroll-loops jak napisałem tworzy kod wolniejszy stosunkowo często (częściej przyspiesza, ale to nie zmienia fakt, że rozwijanie pętli potrafi być szkodliwe) i to we wszystkich kompilatorach (to zależy od programu czy z unroll-loops jest szybszy czy wolniejszy), dlatego lepiej sprawdzić. Poza tymi optymalizacjami jest jeszcze wiele innych (np. -mfpmath=sse, -ffast-math), które mogą przyspieszyć działanie programu – listę optymalizacji z opisem masz pod "gcc -c –help=optimizers", a listę włączonych/wyłączonych optymalizacji masz pod "gcc -c -Q [optymalizacje] –help=optimizers"
Dodam jeszcze że na oko (tzn. patrząc na to co wypluje) -fgcse-* daje dobre efekty. Tzn. nie odkłada wartości co chwila na stos.
No i oczywiście -march=native, PGO oraz inne drobiazgi (man gcc i odrobina inwencji bardzo pomaga). A w ogóle możesz pokazać ten program (źródła)?
Pokazać mogę, czemu niiii, ale wiele osób umrze jak zobaczy mój failcode
więc – nie oglądać przy jedzeniu!
http://dl-client.getdropbox.com/u/28596/Stuff/pin…
+ Makefile http://wklej.org/id/60404/
Na swoją obronę powiem, że pracuję nad zmianą printf w coś "troszkę" bardziej optymalnego.
akurat lepiej printf niż strumienie z c++, które są dużo wolniejsze przez synchronizację (można ją wyłączyć std::ios_base::sync_with_stdio (false);, ale i tak nie wyprzedzi printf'a).
a ten zysk wydajności to tylko na procesorach Intela ? czy optymalizacja w tym przypadku nie jest zależna od platformy ?
Optymalizacja AFAIK nie, ale w kodzie generowanym przez ICC jest dodawane sprawdzanie, czy odpalamy to na "prawidłowym" procu. Tylko, że to już spatchowano
afair niezależnie od procesora – przecież w końcu Intel nie wsadza do swoich prockow dodatkowego kawałka krzemu, który to podwaja prędkość działania go – jeśli użyjesz ICC.
Na liście mailingowej qt znalazłem kiedyś wpis że na athlonie przy jakichś tam operacjach matematycznych icc potrafił być nawet o 60 % szybszy (choć to było chyba w czasach gcc 3 nie 4), dlatego widać że to jest raczej niezależne od procesora. Ale żeby nie było tak różowo dla icc, gcc był chyba wydajniejszy w operacjach na strumieniach o ile sie nie myle.
Sami hakierzy pracują nad tym jądrem
ciekawe kiedy ich pozamykają 
taaa, a mi się podoba ten news bo używa PRAWIDŁOWEGO słownictwa, a nie jakiejś medialnej propagandy wg której haker == włamywacz.
@kwahoo: To, ze mit o rzekomo prawidlowych znaczeniach slowa 'hacker' cieszy sie w srodowiskach zwiazanych z Linuksem spora popularnoscia nie znaczy jeszcze, ze jest prawdziwy. Bo nie jest. Slowo 'haker' na okreslenie osoby wlamujacej sie do komputerow bylo uzywane juz we wczesnych latach osiemdziesiatych. A ludzie znajacy sie na komputerach zwykle okreslali sie mianem 'inzynierow', tak samo jak dzisiaj zreszta.
ty jesteś mit. http://www.etymonline.com/index.php?term=hack
Jak rozumiem np. Kevin Mitnick jest w "środowisku związanym z Linuksem"? W swojej książce (tzn. co najmniej 1) używa słowa haker w znaczeniu osoba znająca się na komputerach a nie włamywacz (z odpowiednim przypisem).
Haker to osoba znająca się bardzo dobrze na programowaniu, która zna wiele sztuczek programistycznych, inaczej haków (ang. hacks). Najzwyczajniej w świecie, a że ktoś nie zna etymologii słowa, jego problem. To tak, jakby się upierać, że zamek jest tylko błyskawiczny – a kamiennych nie ma i nie było.
Niemniej jednak uważam że seth został potraktowany niesprawiedliwie. Plus za humor!
Ja tam gościa (chyba, w sieci nigdy nie wiadomo) nie minusowałem. Od kiedy piszę na LN, staram się w ogóle nie rozdawać ocen
Niektórzy nie rozumieją żartu nawet gdy są uśmiechy wstawione.
To ty nie rozumiesz etymologii. Słowo to powstało na jakiejś amerykańskiej uczelni (mit?) gdy studenci się włamywali do pokoi w których stały komputery.
@trasz, wyżej: Bo wannabe pokroju ESR rozsiewają takie idiotyzmy. Nie mają dosc talentu, więc wmawiają ludziom bzdury.
Smieszne jest to, niedlugo kazdy kto zrobil ./configure && make && make install bedzie hakerem. Bo uzywa luniksa i kompiluje programy!
A jakieś źródło? Bo jesteś raczej osamotniony w swojej teorii.
Jak więc dziś nazwiesz ludzi, którzy byli włamywaczami i nazywali siebie hackerami zanim ruch wolnego oprogramowania (który tak chętnie sobie ten termin przywłaszczył) w ogóle się skrystalizował? Owszem, pionierzy WO mogli być jednocześnie hackerami, ale to nie znaczy, że dziś kogoś można tak nazywać, tylko dlatego, że jest zdolnym programistą.
I ci i ci są hakerami, bo zdaje się, że zarówno programiści MIT czy Harvardu nazywali się tak od lat sześdziesiątych, jak i istnieli hakerzy-włamywacze od mniej więcej tego okresu (tak przynajmniej pisze niejaki Bruce Sterling).
Niemniej jednak niezależnie od powyższego – chyba zawsze ludzi grzebiących w jakiś sposób przy jajkach nazywano albo hakerami albo andrologami.
Problem tylko w tym, że portowanie jajka na inny kompilator to nudna robota, która nie wymaga jakichś szczególnych umiejętności programistycznych, a przede wszystkim przeczytania manuali obu kompilatorów. System jako taki się nie zmienia, kod został napisany, teraz tylko trochę dekoratorów itd. ulega zmianom, małe fragmenty zostają przepisane z pseudostandardu GNU C na ISO 9898 i tyle. Nie wiem czy ma sens nazywanie hackerem kogoś, kto wykonuje praktycznie mechaniczną robotę… Już większym wyzwaniem jest przeniesienie aplikacji z jednego systemu operacyjnego na inny, zakładając że pierwotnie przenośności nie planowano – takie rzeczy to praktycznie codzienność.
Bądźmy szczerzy, jeżeli absolwent lepszej uczelni po informatyce nie jest wstanie tego zrobić to na papier absolutnie nie zasługuje.
Plus za andrologów
Poczytaj kim jest haker!!
Zaiste… Ironia to trudna rzecz…
Ironizować też trzeba umieć
Nie no koniec świata. Jakby 'hakierzy' i emotikony nie były wystarczającą sugestią. Mam nadzieję, że te -17 punktów dla setha(na chwilę obecną) to nie jest przez niezrozumienie ironii, bo to niezbyt dobrze by świadczyło o czytelnikach OSnews.pl
A ja chcę się podzielić plusami z seth [aktualnie +59/-13]! Nie występowałem przeciwko niemu, serio.
Choć gdyby napisał:
[ironia] Sami hakierzy pracują nad tym jądrem
ciekawe kiedy ich pozamykają 
[ironia]
to chyba by nikt minusa nie postawił…
Niektórzy mają po prostu straszną zajawę na punkcie "haker != cracker" że nawet dowcip to dla nich obraza ; )
"Nieznany haker z Broadcom, który służył wiedzą i wsparciem technicznym." – To się chwali
. Pozdrawiam bohatera 
.
Powyższą dyskusję na temat tego kim jest haker chcę nieco rozbudować. Kilka lat wstecz dość intensywnie interesowałem się owym zagadnieniem, więc dorzucę swoje trzy grosze. Otóż mniej istotne jest to 'kim' jest haker a bardziej istotna jest tzw. 'postawa hakera'. W niektórych środowiskach za hakera uznaje się człowieka, który – na ogół – posiada sporą wiedzę na określony temat oraz stara się pokonywać trudności pojawiające się podczas studiowania danego tematu dla własnej – dzikiej
– przyjemności. Poświęca na to dni/tygodnie/miesiące/lata, pogłębia wiedzę, próbuje obejść problem na różne sposoby. Zdarza się, że robi to dla pieniędzy (początkowo to mnie zdziwiło, że zarabianie na 'hakerstwie' jest wg wielu hakerów OK), ale najważniejsza jest satysfakcja z pokonania trudności. Znacznie mniej istotna jest dziedzina w której owy haker się porusza. Otóż nie musi to być wcale informatyka. Równie dobrze może to być elektronika, fizyka czy matematyka (itp. itd.).
Myślę, że jest to najtrafniejszy opis hakera z jakim się spotkałem. Może problem stanowi nazewnictwo – przecież haker kojarzony jest tylko z IT. Z czasem może powstaną inne nazwy innych hakerów
.
Ostatnie zdania to bzdura, ale fajna, bo tylu ludziom bez realnej wiedzy i talentu daje szansę by się tak nazwać. Po co studiować latami, by się naprawdę nauczyć – od teraz wystarczy grać na flecie by zostać hakerem.
Eh, jeszcze raz. Hack narodziło się na określenie studentów włamujących się do sal z komputerami, by je używać. Przeczytajcie tekst tzw. "The mentor", on był znacznie wcześniej niż bicie piany do fetchmaila.
Nazywa się tak też tymczasowe poprawki w kodzie, które same w sobie wołają o pomstę do nieba, tak badziewne to rozwiązanie – doraźne, na szybko i wymaga szybkiej zmiany na coś lepiej przetestowanego. Działa – owszem, ale nic poza tym. W każdej chwili może przestać działać.
Ale hakerem nie jest _żaden_ programista tylko dlatego że zrobił jakiś projekt. To jest stricte związane z penetracją systemu by czerpać z tego korzyści*, kropka. W tym artykule nie wspomniano ani jednego hakera, mimo że wszystkich nazwano tym tytułem. Smutne, jak propaganda robi swoje.
* – niekoniecznie "realne", może to być np. sama zabawa czy nauka. Ale _nie_ chodzi tu o robienie dobrych uczynków i uczenie admina na czym polega jego praca.
Hmm. Zaczynam się zastanawiać czy w pewien sposób ESR (albo ktoś zapewne wcześniej) nie miał racji pisząc o 'kulturze hakerów'. Tzn. 'hakerstwo' to nie tylko znajomość programowania etc. ale także pewien hmm… styl bycia.
Jeśli chodzi o hacki to hackiem nazwałbym także 'obejście' systemu. API systemu/system nie pozwala zrobić A mimo że powinno. Hack to (m. innymi) krótki kod obchodzący to – w nieelegancki acz potencjalnie jedyny możliwy spoób.
Brawa dla intela. Niech się chłopaki wezmą za najnowsze jądro, wyrzucą stare, śmieciowe sterowniki, zbędne moduły i skompilują całość pod x86_64, a może coś z tego wyjdzie. Uprzedzając lament malkontentów siedzących na 486 czy k6 300 – jajko 2.4 jest dla was
. Podejście 'x86_64 only' to przyszłość, a zachowywanie ciągłej zgodności z i386/686 to regres.
Może nie przesadzaj z tym 2.4, aczkolwiek tak mi przyszedł pomysł do głowy, że x64bit_only mogło by być dobrym powodem do otwarcia linii 2.8.x.
Przy okazji obok userspace i kernelspace przydałby się jeszcze driverspace gdzieś pomiędzy, żeby nie zaśmiecać właściwego rdzenia sterownikami do kamer czy tunerów.
Niby po co? Na świecie nie istnieje tylko intel i amd produkujące najnowsze odmiany rodzin x86. Wiele sprzętu przemysłowego działa na niezależnych produktach x86 z gałęzi innych niż najnowsze. Często są to jakieś mikrokontrolery z rdzeniem 486 i zegarem 200 i więcej MHz.
Tylko, że te urządzenia na rdzeniu 486 porażają wręcz wydajnością. Mam na biurku komputerek z procesorem Vortex86SX 300MHz i sorry ale nie znalazłem jeszcze komputera wolniejszego od niego. ARM-y są wydajniejsze od tego czegoś…
http://marcin.juszkiewicz.com.pl/2009/02/20/does-…
O fajny test. Rzeczywiście mój stary Pentium ma większy transfer. Mimo wszystko pracuje znośnie na jajku 2.6.2x analizując trendy forexowe gdzieś w szafie.
Czytuje Twojego bloga i muszę przyznać, że zabawek masz co niemiara
(zazdroszczę).
Wiele z tych zabawek tylko 'przewija' mi się przez ręce – przychodzą i odchodzą.
np 8051 bardzo często spotykany w maszynach i innych urządzeniach nie nastawionych na szczególne obliczenia.
nie samym x86 człowiek żyje
No dokładnie. Właśnie miałem odpowiedzieć strange unknown że 64 bitowy ARM to przyszłość, a dla x86 powinna być tylko gałąź 2.2
…lecz każdym słowem, które pochodzi z ust Bożych…
1. Nie sądze żeby utrzymanie kodu x86 było jakoś szczególnie kosztowne. Większość sterowników już jest. Kod do stronicowania powinien wyglądać podobnie (choć zgoda – nie identycznie).
2. x86 nadal się stosuje. Choćby komputer z którego piszę ma 32-bitowy procesor.
3. Nawet na procesorach 64-bitowych stosuje się systemy 32-bitowe z różnych powodów (hint
ad 2/3.
32 bitowy userspace wcale nie determinuje 32 bitowego kernelspace
Swoją drogą czy jakieś mainstrimowe distro używa takiego hybrydowego rozwiązania? (przestrzeń użytkownika 32 bity, a jądro 64 bity) Wiem o System Rescue CD, które dostarcza taką opcję (dzieki temu np. można się chrootować do 64 bitowych systemów).
Fedora 11 ma tak mieć:
https://fedoraproject.org/wiki/Features/Architect…
Na pewno jest to planowane w nadchodzącej Fedorze 11
debian chyba idzie tak zainstalować
ad ad 2. Wspaniale. Ale mój 32-bitowy procesor determinuje brak 64-bitowego jądra
. A on na razie w zupełności mi wystarcza[1]. Jeśli chodzi o ad 3 to zgoda.
[1] Linux to nie Windows – nie ma służyć do wydawania $$$ by uruchomić nowszą wersję
Istotnie straszne. Wsparcie dla 32bitowych (a fuj) procesorow intela. Toz to prawie jak utrzymywanie portu linuksa na Commodore 64 !
Ja tam zawsze myslalem, ze sterowniki do kernela to sie pisze tak, zeby byly przenosne pomiedzy x86 a amd64 no ale ja to glupi jestem. Jezeli jest kolega w stanie dostarczyc liste "starych i smieciowych" sterownikow bedzie ona nieoceniona pomoca dla developerow kernela. Wszak przyslowie mawia, ze Linus bardziej nawet niz dodane linijki kodu ceni sobie usuniete linijki kodu.
Pozdrawiam,
ale jesli 64bit kernel "kuca do miecza"* co ma miejsce na chwile obecna, to migracja "na sile" w gore jest sporym bledem. zapominasz tez ze nie kazdy obecnie uzywany procek z rodziny x86 ma rozszerzenia 64bit. dlaczego linux mialby sie kierowac tylko na jeden konkretny rodzaj sprzetu (niemal od samego poczatku byl wieloplatformowy).
*"kuca do miecza" – stara karta telewizyjna na pci, uruchomiona pod 32bit jajem/userlandem bardzo ladnie dziala – przy 64bit jaju/userlandzie, ten sam sprzet "przytyka".
"lepiej zoptymalizowany" zabrzmiało tak, jakby coś optymalnego można było ulepszyć (nota bene nasi politycy także szukają "bardziej optymalnych" rozwiązań)
(BPANMSP – na polibudzie zbyt wiele razy odmieniałem słowo "optymalny" przez wszystkie przypadki)
Czy techniki optymalizacji IPO oraz PGO sa opatentowane przez intela?
Jesli nie to czy kompilatory z gcc (przynajmniec g++) stosuja te techniki?
Jesli nie i jesli nie sa opatentowane to kiedy gcc bedzie robic z tych technik uzytek?
Zakladam ze ludzie pracujacy nad gcc pokonczyli te same uczelnie techniczne co ludzie pracujacy nad icc….
Doczytalem ze GCC ma PGO a co z IPO?
Zakladam ze nie ma, ale moze ma inne heurystyki?
PGO jest i działa nie najgorzej. IPO jest w drodze. Na razie można robić sztuczki.
Ludzie, przecież od początku w tekście BYŁO NAPISANE, że GCC używa PGO, ale ponoć intelowski kompilator robi to lepiej. Nie mam natomiast wiedzy na temat IPO.
ROTFL. Co mają uczelnie do rozwoju kompilatora, oprogramowania w ogóle? Hm, idąc tym tokiem rozumowania John Carmack nie był w stanie stworzyć cholernie optymalnych silników gier 3D bo nie ma dosyć przeciętne wykształcenie…
Przypominam, że uczelnia wyższa to nie podstawówka, gdzie wkłada się do łba informacje (jak się niektórym wydaje), a miejsce gdzie wskazuje się kierunki rozwoju i wymaga samodzielnego podążania nimi. Uczelnia nie zrobi z człowieka chociaż kiepskiego programisty…
Ekhm, *'bo ma', przeklęte pisanie na raty…
@Linuksiarz: Pierwsze kompilatory potrafiace automatycznie wektoryzowac kod pojawily sie gdzies ze trzydziesci lat temu. Wektoryzacja kodu w GCC weszla kilka lat temu. Daj im troche czasu.
Dlaczego trzeba kernel przystosowywać do innego niż gcc kompilatora?
Przecież C jest ustandaryzowane. Wiem że są jakieś GNU rozszerzenia, które dają przedziały w case i jakieś inne cuda ale to chyba nie przez to? Czy to znaczy, że kernel nie trzyma się standardów?
Ogólnie rzecz biorąc, kod źródłowy kernela nie jest źródłem cnót. Jak to powiedział Torvalds: "Dijkstra chyba mnie nienawidzi…".
bardzo delikatne okreslenie
az dziw ze trasz sie nie wypowiedzial :>
Napisał
To jest w komentarzach źródeł jądra, jeśli dobrze pamiętam wieść gminną. 
Polecam trzeźwiące komentarze na LWN: http://lwn.net/Articles/320795/
PGO – już kilka lat temu pisali o próbach z PGO w GCC. O ile pamiętam wynik były słabe – tzn. profilowanie (eksperymentowanie) było lepsze od "zgadywania" przebiegu programu o ułamki procent. Dlatego nie zawracali sobie nim głowy.
Czy ktoś ma aktualniejsze info na temat profili w GCC?
man gcc i /-fprofile-generate /-fprofile-use
A jak to wygląda od strony licencji na której jest jądro? Czy linker intela nie dorzuci jakiś własnościowych bebechów? A może tylko kompilator jest intela a linker już nie?
Swego czasu pamiętam, że twórca Tiny C Compiler też chwalił się lepszym kodem wynikowym i szybszym czasem kompilacji. Jeżeli można uzyskać tak duży skok w wydajności jak można przeczytać w newsie, kosztem jedynie zmiany kompilatora to chyba warto w to zainwestować czas i środki.
tcc ma zdecydowanie gorszy kod wynikowy, jak i zdecydowanie krotszy czas kompilacji.
Mam pytanie jak widze do znawców i hakerów.
Gdzie mogę znależć najmniejszy kompilator . Taki do nauki pisania kompilatorów. Najlepiej by uzywał jednak flex i bison. Coś prostego, cos co posłuzyło by mi do nauki pisania czegos dla siebie.
Gramatyka pewnie musiała by być troche uproszczona, ale prosze o pokazanie uzytecznych linków. w google lwasciwie nic nie znalazłem,albo kobyły, albo tylko opis samego lexa
Jeśli chodzi niekoniecznie o C to na stronach llvm masz opis. Co prawda musisz kod w asm sam 'wypluć' ale rezygnując na razie z skomplikowanej alokacji rejestrów etc. wystarczy trzymać wszystko na stosie i ładować do rejestrów[1] przed operacją.
[1] Potem ewentualnie dodać alokacje rejestrów.
Czy takie cos pojdzie pod ubuntu ii nic mi sie nie sypnie bo bym se zapakowal takie jajo