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ę.

żadnych reklam, sama wiedza.

Zarejestruj się na BEZPŁATNY NEWSLETTER i raz w tygodniu otrzymuj najważniejsze wiadmości
ze świata IT, nowych technologii i kryptowalut.

Bez reklam.

  1. Awatar marcinsud
    marcinsud

    Jak jest licencjonowany ten kompilator?

    1. Awatar Sparrow1
      Sparrow1

      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.

      1. Awatar trasz
        trasz

        @Sparrow1: … oraz pod FreeBSD, warto wspomniec. Lezy w portach jako lang/icc.

        1. Awatar morbit
          morbit

          Niestety, tylko i386 i stara wersja.

        2. Awatar trasz
          trasz

          @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.

  2. Awatar krzabr
    krzabr

    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 🙂

  3. Awatar ufoludek
    ufoludek

    Ł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.

    1. Awatar kwahoo
      kwahoo

      Ten fragment może wskazywać, że faktycznie jest tak jak piszesz:

      VendorString w procesorach VIA Nano na “AuthenticAMD” pozwala zwiększyć wyniki benchmarku podsystemu pamięci w PCmark2005 o 10%

      Nie widzę powodu by Intel faworyzował AMD nad Via, która może w ogóle jest dla niego "generyczna".

      W każdym razie, nawet w przypadku takich recydywistów, zasada domniemania niewinności dalej obowiązuje.

      1. Awatar karakar
        karakar

        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.

    2. Awatar Sparrow1
      Sparrow1

      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.

      1. Awatar ufoludek
        ufoludek

        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.

        1. Awatar Sparrow1
          Sparrow1

          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.

        2. Awatar ufoludek
          ufoludek

          @Sparrow1: sorry, ale nie wiesz, o czym mówisz. Doszkól się trochę z tematyki kompilatorów i niskopoziomowych optymalizacji kodu.

        3. Awatar Sparrow1
          Sparrow1

          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.

        4. Awatar Tomasz Woźniak
          Tomasz Woźniak

          @ufoludek: możesz więc wyjaśnić dlaczego podmiana VID powodowała skompilowanie wydajniejszego kodu?

        5. Awatar Tomasz Woźniak
          Tomasz Woźniak

          @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.

        6. Awatar ufoludek
          ufoludek

          @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.

        7. Awatar ufoludek
          ufoludek

          @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.

          Potrafisz to zrozumieć, czy niespecjalnie?

        8. Awatar ufoludek
          ufoludek

          @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.

        9. Awatar ufoludek
          ufoludek

          @Sparrow1 i Tomasz Woźniak: przeczytajcie sobie (najlepiej ze zrozumieniem) to, co poniżej napisał LV.

        10. Awatar Sparrow1
          Sparrow1

          @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.

        11. Awatar Tomasz Woźniak
          Tomasz Woźniak

          @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).

        12. Awatar bies
          bies

          Ufciu: na której to architekturze kod SSE będzie wolniejszy od rep movsb (wklikaj się w linki w notce blogowej z oryginalnym tekstem)?

          A jak już dojdziesz do tego, że w żadnej to nie chrzań więcej.

        13. Awatar ufoludek
          ufoludek

          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.

        14. Awatar bies
          bies

          Nie pytałem o dane na których to będzie wolniejsze a architekturę. A teraz odpuszczając sobie szczególne przypadki: gdzie?

          Co do linku: więcej informacji -> pierwszy link (do bloga) -> ,,got similarly useless answers''.

        15. Awatar ufoludek
          ufoludek

          @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.

        16. Awatar bies
          bies

          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.

        17. Awatar ufoludek
          ufoludek

          @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.

        18. Awatar ufoludek
          ufoludek

          @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.

      2. Awatar jarek
        jarek

        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 🙁

        1. Awatar Tomasz Woźniak
          Tomasz Woźniak

          @jarek: to nie czytaj.

  4. Awatar LV
    LV

    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.

    1. Awatar spy000yps
      spy000yps

      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 😉

      1. Awatar wilq
        wilq

        @spy000yps

        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…

    2. Awatar mormon
      mormon

      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.

      to jest po prostu jedna wielka afera.

      1. Awatar jarek
        jarek

        > 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.

        1. Awatar Tomasz Woźniak
          Tomasz Woźniak

          @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.

          Dotarło?

        2. Awatar jarek
          jarek

          > 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?

        3. Awatar Tomasz Woźniak
          Tomasz Woźniak

          @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".

        4. Awatar moher
          moher

          spowalnianie != nieprzyspieszanie

        5. Awatar Tomasz Woźniak
          Tomasz Woźniak

          @moher: blokowanie przyspieszania = spowalnianie. Tak chyba wynika z fizyki.

        6. Awatar Tomasz Woźniak
          Tomasz Woźniak

          @moher: ale plusa masz za riposte 😀

        7. Awatar moher
          moher

          @Tomlee: oni po prostu nie przykładają dodatkowej siły, więc ani nie przyspieszają, ani nie spowalniają.

        8. Awatar jarek
          jarek

          > nie pisał byś durnot. Po drugie- obowiązku nie mają o ile informują o
          > tym.

          Reklamuja swoj kompilator jako optymalne
          narzedzie do generowania kodu na AMD?
          Nie? To o czym niby maja informowac?

          A skoro optymalizacja działa, to czemu jest blokowana?

          A jest blokowana? Wystarczy podmienic vendor string i ja masz.
          Jesli juz, to AMD blokuje zmiane vendor string.

          > Poza tym prawo to prawo, a taka zagrywka to nieuczciwa
          > walka z konkurencją.

          Pokaz mi paragraf ktory mowi, ze nie inwestowanie zasobow
          optymalizacje kodu dla CPU konkurencji lamie prawo?

          > Czy w przypadku np. MS i hipotetycznie- ukrytej funkcji spowalniającej
          > działanie oprogramowania konkurencji,

          Tu nie ma spowalniania, myslisz troche
          co piszesz czy piszesz co myslisz?

        9. Awatar vries
          vries

          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.

        10. Awatar bobycob
          bobycob

          Zwłaszcza, że za kompilator zapłacić trzeba, a nie jest rozwijany w ramach projektu budowy nowego 100 rdzeniowego x86.

        11. Awatar Tomasz Woźniak
          Tomasz Woźniak

          @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.

        12. Awatar jarek
          jarek

          @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.

          http://software.intel.com/sites/products/collater…

          I pare fragmentow:

          "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.

    3. Awatar mormon
      mormon

      ps. miałem na myśli optymalizację pod architekturę procesorów konkurencji.

  5. Awatar _qaz7
    _qaz7

    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.

    1. Awatar bies
      bies

      Nie. Zależy od procesora na którym kod jest uruchomiony, gulaj za ,,Intel automatic CPU dispatch''.

  6. Awatar wp
    wp

    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!

    1. Awatar LV
      LV

      Weź GCC, zmień mu architekturę docelową… i popatrz, 'ten sam procesor ma różne wyniki!'.

    2. Awatar Madej
      Madej

      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.

  7. Awatar aegis maelstrom
    aegis maelstrom

    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).

    1. Awatar wilq
      wilq

      @ aegis maelstrom

      brawo zasługujesz nie tylko na plusa… 😉 ale na komentarz z poparciem

    2. Awatar mor
      mor

      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.

    3. Awatar Madej
      Madej

      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.

      1. Awatar bobycob
        bobycob

        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?

  8. Awatar Iska
    Iska

    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.

    1. Awatar wilq
      wilq

      stary proszę powiedz że to tylko wygłupy lub trolowanie itp a nie na serio…

      1. Awatar sprae
        sprae

        Za dużo Korwina 😉

        1. Awatar Nowaker
          Nowaker

          Korwin to akurat w wielu kwestiach ma bardzo dużo racji. ;]

    2. Awatar Szeku
      Szeku

      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 !.

  9. Awatar Quinn
    Quinn

    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

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *