Kompilator Intela spowalnia kod na procesorach konkurencji
Czy zastanawialiście się, czy Intel wykorzystuje swój kompilator do walki z AMD i VIA? Jeśli nie, to warto poznać kolejną ciemną stronę potentata z Doliny Krzemowej.
Kompilator Intela potrafi generować różne wersje kodu w zależności od zestawu instrukcji(takich jak SSE2/SSE3), jakie wspiera dany procesor. System identyfikuje procesor przy uruchomieniu programu i w zależności od wyników detekcji wybiera optymalną ścieżkę kodu (odpowiada za to tzw. CPU dispatcher).
Jednakże dispatcher Intela wykrywa nie tylko, jaki konkretnie zestaw instrukcji jest obsługiwany, ale także na procesorze jakiej marki został uruchomiony. Odbywa się to poprzez sprawdzenie tzw. VendorString, czyli napisu który jest zakodowany w każdym procesorze. Jeśli zostanie wykryte, że jest to procesor Intela(tzn. VendorString ma wartość “GenuineIntel”), to wykonywana jest optymalna ścieżka kodu. Natomiast wykrycie procesora konkurencji powoduje w większości przypadków automatyczny wybór najwolniejszej ścieżki kodu, nawet jeśli procesor jest zgodny i wspiera wykonywanie szybszego kodu.
Mogłoby się wydawać, że jest to kolejna z wielu legend, ale okazuje się że można to sprawdzić. Otóż redaktorzy ArsTechnica odkryli, że zmiana VendorString w procesorach VIA Nano na “AuthenticAMD” pozwala zwiększyć wyniki benchmarku podsystemu pamięci w PCmark2005 o 10%, natomiast zmiana na “GenuineIntel” owocuje blisko 50% poprawą wyników. Niestety procesory AMD mają zablokowaną taką możliwość, więc trudno ocenić jaki jest wpływ kompilatora Intela na ich wydajność.
Całą sprawą zajęła się Federalna Komisja Handlu USA, która wezwała Intel do naprawienia szkód m.in. poprzez naprawę kompilatora, rekompensatę szkód jakie ponieśli jego użytkownicy oraz publiczne ogłoszenie konieczności ew. wymiany kompilatora na nowszą wersję.
Z szybkiego wyszukania na stronie Intela wynika, że można zakupić komercyjną wersję działającą m.in. pod Windows i Linuksem albo ściągnąć bezpłatną wersję do użytku niekomercyjnego działającą pod Linuksem.
@morbit: Glownie dlatego, ze z czasem GCC skutecznie nadrobilo zaleglosci do ICC i nie chce sie ludziom bawic w portowanie, skoro jest w portach swieze GCC. A od ladnych warningow przy kompilacji jest clang.
Na pewno w taki aby nie można było ich za takie numery pozwać do sądu , kierownictwo intela nie jest głupie i nie śpieszy im się do wydawania kolejnych mln $ w formie kar za nieuczciwą konkurencje 🙂
Łojezu, ludzie, nie róbta afery. Oprócz zestawu instrukcji różne procesory mają też różne możliwości parowania instrukcji i różne pipeline'y.
Kompilator Intela optymalizuje pod procesory Intela. Generuje jakieś tam sobie kody zoptymalizowane pod Intela + kod "generyczny", który jest zoptymalizowany pod architekturę "generyczną" (cokolwiek by to nie znaczyło).
Ich detekcja opiera się na id vendora, bo tylko w ten sposób mogą dostać 100% pewną informację, jakiego się po procku zachowania mogą spodziewać. Bez tego wykrywacz musiałby przeprowadzać serię benchmarków, jak które instrukcje w połączeniu z którymi się zachowują. Zbenczmarkowanie tego bynajmniej nie było by proste.
Żeby tropić aferę trzeba by wykazać, że ten kod "generyczny", który jest celowo generowany tak, żeby u konkurencji działał wolniej, na przykład celowo wykorzystując jakieś jej słabe strony, celowe wyrównując kod/dane tak, żeby rozwalać cache itp.
A ja widzę powód. Via produkuje procesory które teoretycznie były by konkurencją dla ich Atomów (AMD już też, ale dopiero od niedawna). Poza tym taka różnica mogła by być pewnym rodzajem alibi.
Ich detekcja opiera się na id vendora, bo tylko w ten sposób mogą dostać 100% pewną informację, jakiego się po procku zachowania mogą spodziewać.
Sugerujesz że implementacja np. SSE2 przez AMD jest w jakiś sposób niezgodna z intelowską? No sorry, ale to jest po prostu bullshit. Programiści za ciężką kasę kupili kompilator, który jak się okazuje celowo generuje wolny kod dla kilkudziesięciu procent procesorów na rynku. Doskonale wiesz że trudno tu cokolwiek udowodnić, bo Intel nie ma obowiązku wspierania procesorów konkurencji. Ale z drugiej strony można się spodziewać, że skoro wykrywane są obsługiwane zestawy instrukcji to działa to jednakowo dla wszystkich procków x86. A okazuje się że tak nie jest, a w dodatku mało kto o tym wie. A nawet słabo zoptymalizowany kod w wielu przypadkach okaże się szybszy od zupełnie nie zoptymalizowanego.
Nie, nie jest niezgodna. Instrukcje są te same. Opcode'y takie same. Wynik ich działania jest taki sam. Ale już timingi i możliwości wykonywania równolegle dwóch instrukcji na różnych prockach są zupełnie różne.
Przecież nie chodzi o to, że dany kod będzie z różnych względów chodził nieco wolniej, tylko o to że w ogóle nie będzie miał szansy uruchomienia-bo kompilator(tfu! marketing 😉 ) arbitralnie uznał tak, a nie inaczej. Gdyby ten sam kod działał wolno-to ok, procesory AMD mają inne uwarunkowania i tyle. Ale żeby doprowadzić do takiego zachowania kompilatora, ktoś musiał celowo wprowadzić kod który "wycina" szybsze ścieżki kodu. W przeciwnym wypadku zmiana VendorString nie miałaby znaczenia. I to jest naprawdę brzydka zagrywka, zwłaszcza biorąc pod uwagę, że te kompilatory przodują zwłaszcza przy obliczeniach naukowych(głównie Fortran). A np. naukowcy którzy z nich korzystają nie muszą sobie zdawać sprawy z niuansów optymalizacji-właśnie po to używają automatu.
Sorry, ale jak jesteś takim kompilatorowym geniuszem to może podziel się z nami wiedzą, bo jak dotąd nic merytorycznego nie napisałeś. Uwzględnianie wsparcia dla zestawu instrukcji to nie jest żadna "niskopoziomowa optymalizacja kodu", tylko elementarna cecha każdego szanującego się kompilatora.
@ufoludek: acha- przez przypadek. Mógłbym się założyć iż kod kompilowany na ICC pod Intelem a dopalony na AMD zadziała w każdym razie szybciej niż skompilowany w ICC na AMD i odpalony pod AMD. Rozumiem, że to oczywiście też byłby przypadek.
Od siebie- ludzie tłumacza przypadkowością rzeczy jakich nie pojmują, albo nie chcą przyjąć argumentacji. Osobiście nie wierzę w przypadki.
@Tomasz Woźniak: nie skompilowanie, tylko wybranie. Przez przypadek się okazało, że charakterystyka procka jest podobna do intelowych i zadziałało szybciej, ale zakładać czegoś takiego to Intel nie może.
@Sparrow1: nie, nie jestem geniuszem, natomiast jestem świadom prostego faktu, że IDENTYCZNY kod w assemblerze może działać znacząco szybciej lub wolniej w zależności od tego, na jakim procesorze go odpalisz. IDENTYCZNY kod W ASSEMBLERZE.
Kompilator Intela generuje kod w assemblerze. W kilku wersjach zoptymalizowanych pod różne architektury, bo TYLKO I WYŁĄCZNIE na nich wie, jak go dobrze zoptymalizować. Na pozostałych architekturach wybiera kod JAKIŚ, JAKOŚ zoptymalizowany, ale niekoniecznie optymalny na przykład na AMD czy na VIA.
Na jednej architekturze opłaca się użyć dla skalarów SSE całkiem zamiast FPU. Na innej opłaca się mieszać SSE z FPU. Na innej dla operacji na skalarach SSE się nie opłaca w ogóle.
Intel może czynić 100% założenia tylko odnośnie swoich procków, które identyfikuje po vendor id. Inne architektury przez przypadek mogą się zachowywać podobnie, ale Intel tego zakładać nie może.
@Tomasz Woźniak: ziom, pliz… jak sobie skompilujesz kod przy pomocy gcc z opcją -march=native (czy jak ona się tam teraz nazywa) na AMD, to też dostaniesz kod działający wolniej po odpaleniu na Intelu.
@ufoludek: czy ty potrafisz zrozumieć, że celowe ignorowanie raportowanych przez CPUID ficzerów NIE JEST uczciwe? Że wybranie LOSOWEGO kodu SSE prawie na pewno zaowocuje SZYBSZYM wykonaniem (np. ze względu na prefetch do cache'u procesora) nawet jeśli nie wszystkie instrukcje są dla danego procka optymalne? Czy wreszcie skończysz z udawaniem bardziej świętego od papieża, skoro nawet Intel nie protestuje i uznaje swój błąd?
Wiesz trollowanie jest fajne, kiedy robisz idiotę z adwersaża, niestety Ty robisz idiotę z siebie.
@ufoludek: ziom- pliz… przeczytaj mój post jaki komentujesz ze zrozumieniem. Post LV przeczytałem wcześniej i nadal jakoś nie potrafię zrozumieć dlaczego optymalizacja działa skoro nie powinna (skoro jest blokowana).
biesiu (skoro już tak zdrobniale): na każdej dla rozmiaru bloku mniejszego niż 4, zwłaszcza jak bloczek jest niewyrównany?
Also: trochę poklikałem, i ni choroby nie widzę nic o wybieraniu rep movsb zamiast kodu SSE. Widzę natomiast o wybieraniu FPU zamiast SSE.
Możesz wskazać konkretnego linka, bom ciekaw.
@bies: no i Ci odpoowiedziałem, że na każdej architekturze w tym szczególnym przypadku. Ty twierdziłeś, że na żadnej. Ja Twoje twierdzenie sfalsyfikowałem pokazując jeden wyjątek.
Poza tym kliknąłem w ten link, i sorry, ale po prostu manipulujesz. Ten case to nie jest "SSE vs rep movsb" (które faktycznie byłoby czerstwe), tylko "SSE vs kombinacja rep movsd/rep movsb", które już jest 4x lepsze, a na prockach intela (ta daaaa) (wg ich dokumentacji) przy blokach większych niż 76 bajtów rep movsd jedzie blokami po 16 bajtów, co już jest jakby porównywalne z prostą pętlą na SSE, czyż nie?
Za "Intel®64 and IA-32 Architectures Optimization Reference Manual":
Fast string (ECX >= 76: excluding REP MOVSB): the processor implementation
provides hardware optimization by moving as many pieces of data in 16 bytes as
possible.
Se AMD zrobiło badziewną implementację rep movsd, to se ma.
Nie, nie odpowiedziałeś. Pisałeś, że na jednej arch. opłaca się użyć SSE a na innej FPU. Sugerując, że Intel używa SSE bądź nie na podstawie arch. No to zapytałem na jakiej podstawie używane jest rep mosvb (nie mosvd — to różnica). I wtedy wyjeżdżasz z małym buforem — otóż mały bufor to nie architektura. To optymalizacja algorytmu.
Teraz Twój mały ,,risercz'' z google i PDF-ami Intela. Zauważyłeś w ogóle co cytujesz? Masz pojęcie czym różni się movsb od movsd, czy dla Ciebie to dwa magiczne ciągi znaków a assembler to nazwa przylądka w Nowej Zelandii?
Nikt normalny nie używa rep movsb do kopiowania ciągów dłuższych niż 3 bajty. Oprócz Intela w kompilatorze 8.0 na architekturach (to nie jest dobre słowo, chodzi o producenta — ale skoro już zacząłeś…) non-Intel.
I masz jakiś problem z czytaniem /.? Czy może umknęło Ci:
,,On any non-Intel processors, it specifically included an alternate code path for "memcpy" that actually used "rep movsb" to copy one byte at a time, instead of (for example) "rep movsd" to copy a doubleword at a time (or MMX instructions to copy quadwords). This was probably the most brain-dead memcpy I'd ever seen, and was around 4X slower than even a typical naive assembly memcpy:''
Tak, to co wziąłeś za ,,kombinacja rep movsd/rep movsb'' to jest ,,typical naive assembly memcpy''. To nie jest kod Intela! Dotarło!?
Podsumowując: albo problemy z czytaniem ze zrozumieniem. Albo problemy z podstawami asm.
@bies: mój błąd, źle przeczytałem. W przypadku memcpy masz rację.
Natomiast nadal będę się zapierał, że opieranie się na vendor id nie jest niczym złym, bo jest jedyną 100% pewną metodą na wybranie optymalnej ścieżki na prockach intela.
@self: ugh, źle to zabrzmiało tak, jak to sformułowałem 🙂 powinno być nie "na prockach intela" tylko "na prockach, których charakterystykę mogą bezpiecznie założyć, że znają".
Tak, oznacza to w zasadzie to samo, ale pierwsza forma sugeruje niecne zamiary, a druga, że to jednak wzgląd techniczny. Moim zdaniem to nadal był wzgląd techniczny.
Gdyby szefostwo OSnews mialo za grosz elementarnej przyzwoitosci,
usuneloby ten smiec sparrow'a. Przeciez ten chlopak nie wie o czym
pisze i na dodatek sieje FUD. Co za gnoj i wodorosty sie tu robia 🙁
Za przeproszeniem, ale strategie optymalizacji dla różnych architektur są diametralnie różne. Nawet pomiędzy Pentiumem III a 4 była ogromna przepaść, kod optymalizowany dla P4 na PIII był zwyczajnie mocno niewydajny (zakładając, że nie używał SSE2/3 – niedostępnych w PIII).
.
Dla przykładu, dla FPU – u AMD opłaca się nadużywać obrotów stosu FPU bo są `wykonywane` już w dekoderze instrukcji, zaś tak zoptymalizowany kod na procesorach Intela będzie nawet o kilkadziesiąt procent wolniejszy. Nie ma tu mowy o celowym `spowalnianiu`, to po prostu różnice w architekturze pozwalające osiągnąć lepszą wydajność przy optymalizacji pod ten konkretny procesor.
.
Ech, wystarczy przejrzeć manuale Intela i AMD żeby zobaczyć jak bardzo różni się czas wykonywania wielu instrukcji i jak różne są strategie optymalizacji. Wiele konstrukcji ma sens tylko na konkretnej architekturze, wspomniany P4 był tak `rewolucyjny`, że ani kod optymalizowany pod wcześniejsze, ani późniejsze procesory Intela nie jest dla niego optymalny, może być nawet o te 10-20% wolniejszy niż specjalnie pod P4 kompilowany.
.
Trudno żeby kompilator Intela, dedykowany procesorom Intela, miał zaimplementowane i dopieszczone strategie optymalizacji kodu maszynowego dla diametralnie różnych procesorów konkurencji.
.
Kolejny durny FUD psujący człowiekowi humor przed snem.
W zasadzie, to ta "sprawa" była już znana od dawna – na slashdot 5 lat temu pojawił się artykuł "AMD Alleges Intel Compilers Create Slower AMD Code". Ale wydaje mi się, że wcześniej też coś o tym pisano.
To o czym piszesz, to prawda. Ja nie rozumiem o co ktoś zrobił tyle szumu – Intel nie ma obowiązku optymalizacji generowanego kodu pod procesory konkurencji. Równie dobrze można by było żądać, żeby programiści optymalizowali tak samo dobrze programy pod każdy system na którym one działają.
Pięcioletni odgrzewany kotlet, to idealny temat na news w osnews 😉 Tutejsi wolnościowcy muszą popluć jadem na duże korporacje 😉
gdybyś nietutejszy geniuszu poczytał oryginał i kilka innych materiałów komentujących sprawę zapewne zrozumiałbyś o co chodzi i głupot nie pisał…
sprawa rozgrywa się pomiędzy intel/amd/federalna komisja handlu czyli pomiędzy dużymi korporacjami i jednym z najpotężniejszych regulatorów otwartego obszaru rynkowego na świecie… czy możesz mi powiedzieć co tu mają do rzeczy opinie bywalców portalu osnews.pl dotyczące korporacjonizmu globalizacji itp.?
zwykłe manewry i strategiczne gierki nie rozumiem o co chodzi
wspomniana federalna komisja handlu rządu usa podjęła działania regulacyjne w sprawie niekonkurencyjnych zachowań intela (zresztą w ramach prowadzanego postępowania nadzorczego które zostało wznowione po starciu intel/ke). Zajęto się zarzutami amd w sprawie kompilatora… gdzie te twoje kotlety mądralo? sprawa jest bardzo aktualna… fakt kilka lat chłopakom zeszło ale takie jest życie…
fakt… tytuł newsa może nie jest najszczęśliwszy ale wystarczy zwrócić uwagę autorowi a nie szydzić ze wszystkich dookoła nawet gdyby mieli inne poglądy.. ale to kwestia kultury
@Sparrow1
może rozważysz zmianę tytułu na "federalna komisja handlu podejmuje działania w sprawie niekonkurencyjnych rozwiązań w kompilatorze intela"
@do wszystkich od "szumu"
szum to byłby gdybyśmy o tym słyszeli przez tydzień w cnn cnbc foxnews sky…
regulatorzy są od tego aby podejmować działania mające na celu utrzymanie konkurencji w danej branży… jeżeli komisja handlu się na to zdecydowała w tym wypadku na wniosek amd jakieś przesłanki muszą do tego istnieć…
ciekawe jak można autorytarnie stwierdzić że intel sobie może robić co chce? koszmar!! nawet gdy ktoś kocha tę firmę/produkty na zabój to przecież tym bardziej powinno zależeć mu na zakupie za niższa cenę a to zapewni tylko konkurencja…
no tak, prawda że kompilator intela nie robi optymalizacji pod architekturę procesorów. ale w ten sposób jak wyjaśnisz te ponad 40% różnicy? jeśli ICC jest wykorzystywane w benchmarkach albo w grach do optymalizacji kodu, to jakie to powoduje nieprawidłowości w wynikach testów, ważnych przecież dla potencjalnych klientów.
w ten sposób procesory intela prawie zawsze będą lepsze od konkurencji. np w grach jest dużo operacji przesyłania bloków pamięci.
> ale w ten sposób jak wyjaśnisz te ponad 40% różnicy?
Bardzo prosto, nikt nie wie tyle o procesorach Intela co sam Intel.
Najwyrazniej potrafia wydusic te ekstra 40% ponad ustandaryzowany
kod wynikowy.
> w ten sposób procesory intela prawie zawsze będą lepsze od konkurencji.
> np w grach jest dużo operacji przesyłania bloków pamięci.
Nie to znaczy, ze firma ktorej zalezy na wydajnosci moze:
1. Poszukac kompilatora ktory da przyzwoity kod bez wzgledu na CPU.
2. Zmodularyzowac sekcje krytyczne i skompilowac na kompilatorach
optymalizowanych pod konkretne platformy i dynamicznie je ladowac.
3. Zaznaczyc, ze jej soft optymalnie pracuje na platformie X.
4. Rozprowadzac zrodla i zwalic ich kompilacje na odbiorce softu.
> to jest po prostu jedna wielka afera.
Afera jest poziom niekompetencji i absurdalna wrecz
tendencyjnosc niektorych newsmanow.
@jarek: wiem, że news uznałeś za chłam, ale przeczytać ze zrozumieniem powinieneś- skoro komentujesz. Optymalizacja pojawiła się po zmianie VendorID- czyli wyjaśnię raz procek powiedział- jestem VIA i skompilowany pod nim kod działał wolno, raz procek powiedział jestem INTEL i po kompilacji zadziałał szybciej. To był ten sam procek, tylko udał przed kompilatorem że jest czymś innym.
> Optymalizacja pojawiła się po zmianie VendorID- czyli wyjaśnię raz
> procek powiedział- jestem VIA i skompilowany pod nim kod działał wolno,
> raz procek powiedział jestem INTEL i po kompilacji zadziałał szybciej.
I czego to dowodzi poza tym, ze kompilator po wykryciu
Intelowskiego vendor string uruchomil zaawansowana optymalizacje,
ktora zapewne poprawila tez wydajnosc na nie-Intelowskich CPU.
Czy Intel ma gdzies obowiazek pompowac naklady na optymalizacje
kodu pod CPU konkurencji, jak ktos juz tu napisal, odpalaja
pewnie na nich jakis generyczny optymalizator i tyle.
Dotarlo?
@jarek: po pierwsze- po co te nerwy? Jakbyś czytał ze zrozumieniem to nie pisał byś durnot. Po drugie- obowiązku nie mają o ile informują o tym. A skoro optymalizacja działa, to czemu jest blokowana? Poza tym prawo to prawo, a taka zagrywka to nieuczciwa walka z konkurencją.
Czy w przypadku np. MS i hipotetycznie- ukrytej funkcji spowalniającej działanie oprogramowania konkurencji, też szastałbyś zdaniem, iż MS nie "ma obowiązku pompować nakładu na optymalizację kodu konkurencji".
Ja muszę się zgodzić z Tomaszem Woźniakiem. Jakie dodatkowe siły? Jakie przyspieszenie? Brak optymalizacji to niewykorzystanie potencjału procesora. Innym słowy gdy celowo się źle optymalizuje to zmniejsza się wartość takiego procesora.
@jarek: echhh… ciężko ci przyznać, że napisałeś bzdurę- co? Jako, że nie lubię dyskutować z ludźmi nieuznającymi racji innych niż ich własna- potraktuj tą odpowiedź za moją ostatnią. Możesz sobie uznać, że mi dosunąłeś.
1. Informować powinien (Intel) o tym, że ich kompilator generuje optymalny kod tylko na procesorach Intel.
2. Podmiana Vendor ID to tylko obejście problemu. Normalne byłoby gdyby optymalizację dawało by się wymusić jakimś parametrem. To co piszesz o VID to czysty bełkot.
3. Co do znajomości prawa- nieinformowanie o braku optymalizacji pod procki konkurencji podchodzi pod wprowadzanie w błąd. Dowód z VendorID jest tak oczywisty, że będzie ugoda i przepraszanie. Założysz się? US to nie nasza umęczona Rzeczpospolita ze zgniłym systemem sądowniczym.
4. Jest spowalnianie- przecież wynikowy kod działa wolniej. Co więcej- celowe spowalnianie. Więc póki co- piszę co myślę. Ciebie oczywiście o myślenie przed odpowiedzią podejrzewać nie będę.
Miłego trollowania.
@jarek: echhh… ciężko ci przyznać, że napisałeś bzdurę- co?
Czy bezmyslne powtarzanie tej mantry to jedyny sposob
w jaki jestes w stanie dyskutowac? Powtorz jeszcze z kilka
razy ze nie mam racji, to Twoja racja stanie sie Twojsza.
> 1. Informować powinien (Intel) o tym, że ich kompilator
> generuje optymalny kod tylko na procesorach Intel.
"Each compiler delivers advanced capabilities for development of
application parallelism and winning performance for the full range
of Intel® processor-based platforms."
"mathematical functions for engineering, scientific and financial
applications requiring high performance on Intel® platforms"
Itd, czyli wszystko sie zgadza.
> 2. Podmiana Vendor ID to tylko obejście problemu. Normalne byłoby gdyby
> optymalizację dawało by się wymusić jakimś parametrem.
Gdzies napisalem inaczej, czy znow dyskutujesz ze swoimi urojeniami?
> 3. Co do znajomości prawa- nieinformowanie o braku optymalizacji pod
> procki konkurencji podchodzi pod wprowadzanie w błąd.
Paragraf w koncu jakis podasz czy to Twoja kolejna bezmyslna
"tak mi sie wydaje" mantra?
> 4. Jest spowalnianie- przecież wynikowy kod działa wolniej.
Nie ma przyspieszania – dlatego kod wynikowy dziala wolniej.
nie chce mi się sięgać do oryginalnego tekstu- ale napisano tu, że kod wynikowy zależy od procesora na którym jest wykonywany build – a z tego by wynikało, że developer buildujący aplikację na prockach AMD/VIA wytworzy wolniejszy kod nawet dla docelowego procesora Intela.
Czytacie ze zrozumieniem? "że zmiana VendorString w procesorach VIA Nano na “AuthenticAMD” pozwala zwiększyć wyniki benchmarku podsystemu pamięci w PCmark2005 o 10%, natomiast zmiana na “GenuineIntel” owocuje blisko 50% procentową poprawą wyników"
Ten sam procesor, z podmienionym VendorString ma różne wyniki!
Bo procesory różnią się trochę bardziej, niż tylko zestawem instrukcji, które potrafią wykonać.
Jakby Intel coś kombinował, to po zmianie VIA na AMD nie byłoby różnicy. A skoro jest, oznacza to, że kompilator jednak stara się zoptymalizować kod pod znany mu procesor (te wyniki sugerują, że VIA Nano nie jest obsługiwany przez ten kompilator) .A że na VIA Nano kod Intela wykonuje się szybciej, oznacza to jedynie, że ten procesor jest bardziej podobny do Intela niż AMD.
Tezy artykuł nie da się inaczej sprawdzić, niż wykonanie podobnych testów na procesorze AMD i Intel. Ale z artykułu wynika, że nie jest to niestety proste.
Stara sprawa, o dochodzeniu antymonopolowym i brudnych sztuczkach w kompilatorze pisano szeroko w 2009.
Niemniej warto ją poruszać, bo jak widać polski Internet jest daleko w tyle. I jak zwykle na OSNews pojawia się masa głupich komentarzy udowadniających, że autor nie wie o co chodzi i powinien najpierw coś przeczytać.
Oczywiście, że implementacja instrukcji między producentami, a nawet rodzinami procesorów może być zupełnie inna. Co nie zmienia faktu, że nawet amerykańska FTC twierdzi, że Intel umacnia swoją pozycję monopolistyczną przez dostarczanie kompilatora, który umyślnie generuje gorszy kod dla konkurentów. Co ciekawe, Intel półgębkiem przyznał się do tego w swojej ugodzie z AMD.
http://www.dailytech.com/article.aspx?newsid=1715…
Ze zrozumieniem tego zarzutu nie mają problemu konserwatywni Amerykanie z Dailytech. Historia praktyk monopolistycznych Intela jest długa jak historia PC.
Tylko oczywiście na polskim OSNews pojawia się grupa urodzonych wczoraj, którym się wydaje, że Intel "nie robi nic złego", albo "że im wolno".
Nope, prawo antymonopolowe mówi jasno – nie wolno. Jeśli im to zostanie udowodnione, dostaną olbrzymią karę w swoim własnym kraju (i pewnie też w innych miejsach na świecie).
No ja też nie rozumiem tego technicznego bełkotu, ale wiem jedno: nie podoba mi się monopol Intela i chciałbym, żeby procesory AMD były tańsze, bo jestem lojalnym klientem tej firmy. Także masz plusa ode mnie.
Ale my dyskutujemy z artykułem sparrow1 – artykuł stawia tezę, że kompilator intela spowalnia kod na inne procesory i na uzasadnienie tej tezy podaje wyniki testów. A z tych wyników testów to nie wynika.
Zresztą w artykule do którego link podałeś jest jedynie napisane, że FTC jedynie oskarża Intela o zły kompilator, a że został w tej sprawie wydany wyrok.
Wiesz to może mieć związek z tm, że kompilator generuje kod bez wyroku sądu, komisja nie jest sądem i co najwyżej nałoży karę.
Masz chyba problem ze zrozumieniem artykułu – co w takim razie wynika z tego testu, że procesory VIA są wolniejszy gdy nazywają się VIA. Są natomiast 2x szybsze gdy nazywają się Intel?
Nie wiem czym się podniecanie. Intel łamie prawo i co z tego? Kto powiedział, że to prawo jest DOBRE? Picie wódki w meczecie w Iranie łamie prawo, współżycie z 12 w wielu państwach prawa nie łamie. Ja bym się jednak nie stawiał znaku równości pomiędzy prawem i dobrem.
Intel, prywatna firma, może sobie robić co chce – nie chcesz, nie używaj.
A mi się wydaję że nie może. Nie możemy tak sobie rozpatrywać firmy jako całości. Kompilator to kolejny produkt firmy X i dopóki pracuję tak samo jak z posesorami x jak i y jest ok. W tym przypadku nie jest ok !
To jak najbardziej są działania monopolistyczne bo opisany kompilator nie jest sprzedawany jako jedna całość w pakiecie do procesora. Lecz konsument nabywa coś co każe mu korzystać także z innych produktów danej firmy. W związku z czym ponosi on dodatkowe koszty których nie był świadomy przy nabywaniu podstawowego produktu !.
No bez jaj! Zaraz wysyłam protest do Citroena, że jego zestaw kluczy nie pasuje do mojej Renówki 😉
A niech sobie sami zrobią kompilator do swoich procków i po bólu.
Dodaj komentarz