Docela hloupá ochrana...
Bude se někdo soudit?

rekl bych ze intel je zoufaly hold uz se prodava 80% procesoru od AMD mluvime li jenom o procesorech do Detskopu :))

Uplatky, nefair hra... typickej Intel. Me to teda neprekvapuje. Staci se letmo podivat na zalobu co pred nedavnem podalo AMD na Intel.. i kdyby byla jen pulka veci z toho pravda tak je to pro me duvod proc si od Intelu jen tak neco nekoupim

Velký podfuk, ne malý!

Presne, typicky trapny, lzivy marketingovy podfuk ala intel vydavany za zazracnou technickou vyhodu kterou disponuje jedine on.
A pak se nekteri divi ze se casteji nez drive objevuje v diskuzich "AMD Rulezz" a i kdyz sam nemam takoveto vyrazy nijak extra v oblibe, tak i kdyz se neda podle teto zpravy rict ze "AMD Rulezz" tak ale urcite jde rict ze "Intel Suxx"
(nehlede na to ze kazdeho trochu mysliciho cloveka napadlo ze CPU intel nemaji zadnou zazracnou schopnost ktera by tohle umoznila a zaroven neumoznovala u kterehokoliv jineho konkurencniho CPU, a zvlast kdyz ma i K7 vyssi vykon v multitaskingu nez P4 s HT [kauza s manipulaci PCMarku ve prospech intelu] a kdyz dnesni dvoujadrove K8 maji rychlejsi komunikaci mezi jadry nez ma Intel)

Spise nez nize uvedene duvody mi takova informace o vyjimecnosti intelovych siliconu prijde smesna kvuli kompatibilite. Ve 32 bitech je to jasne, kopatibilita je proverena roky a AMD podporuje dokonce i SSE a SSE2. V 64 bitech je to srejna kava, protoze kdo od koho prevzal instrukcni sadu? Prece Intel od AMD. Napr. proto Microsoft odkladal vydani 64-bi Win XP, dokud Intel neimplementuje instrukcni sadu a nevyda aspon 1 64-kovy procik.
Jen do toho AMD a bud aspon skoro takovym hracem jako Intel, aby se mi 2-jadrove cipy hezky priblizily:)

Ja mam jen trosku strach jestli ted AMD malinko nezaspalo a Intel ho s prichazejici generaci procesoru zase nezatlaci zpatky...

rok stary prispevok z privatneho fora V-ray render pluginu do 3dsmax, kde vyvojar pluginu pise:

"You may have heard that AMD filed an antitrust case against Intel this summer; one of the allegations is that the Intel compiler purposefully generates code that runs slower on AMD processors than on Intel machines. Well, it is true - just made a few tests this week-end... Code compiled with recent versions of the Intel C++ compiler runs about 10% slower on AMD machines. Now guess which compiler we are using to build V-Ray.
Luckily, our development machines are AMDs, and since newer compiler versions seemed to generate slower code, we are still using an older version that is much less sensitive to the processor type. Still, it was quite a shock when I found out about this... "

a este

"This weekend I examined the code generated by versions 7.1 and 8.1 of the compiler. With general settings, version 7.1 generates code that virtually does not depend on whether the processor is genuine Intel or not. However, version 8.1 generates code that is much more dependent on the processor type. Comparing them head to head, the 8.1 code was a few percent slower than the 7.1 code on my dual Opteron machine."

hmm "fikfik" hezky ale pro nas ne scela dobre vybavene lidi anglictinou je to jen zpousta pismen :-)

2 viki: No, v podstatě se tam píše, že Intelovský C++ kompiler vytváří záměrně takový kód, který na AMD procesorech běží zhruba o 10% pomaleji než na srovnatelných Intelech. Že vyvíjejí pluginy do 3D Maxu a tak je napadlo si to vyzkoušet a když na to přišli, tak se vrátili ke staré verzi kompileru, která tímhle "neduhem" netrpí.

fikfik> A co je na tom divnyho? To, ze maji procesory stejnou instrukcni sadu, preci neznamena, ze maji stejny jadro? Takze nemaji ani stejny casovani instrukci, dekodovani, atd. Intel C++ je opravdu dobry prekladac a snazi se vymacknout kazdy tik, takze provadi scheduling instrukci tak, aby to vyslednemu procesoru co nejlepe vyhovovalo. No a co je divneho na tom, ze INTEL C++ jaxi nepodporuje specializaci/scheduling instrukci pro AMD? Ostatni prekladace (gcc, M$) se k AMD v podstate znaji a jsou schopny generovat "blended" kod, kterej bezi zhruba stejne dobre na obou platformach. Potiz je, ze tyhle prekladace nejsou tak dobry (co se tyce kvality generovaneho kodu a optimalizaci) jako Intelskej, takze pokud nejaka firma vyviji SW, kterej skutecne mocne pocita a taky potrebujou vymacknout kazdej tik z CPU, pak sahnou po Intelskym prekladaci.

Byla tu zminovana i ta zaloba AMD na Intel. V ni se napr. tvrdi, ze Intel C++ zamerne zdrzuje kod na AMD. Tak to NENI pravda a to je lez. Ve skutecnosti je to tak, ze pokud Intel C++ chce pouzit nejaky speciality CPU (treba SSE), tak se nejdrive zepta pomoci instrukce CPUID, jestli to je ten spravnej typ/model procesoru. A to se podle IA-32 manualu dela tak, ze "Always begin by testing for the "GenuineIntel," message in the EBX, EDX, and ECX registers when the CPUID instruction is executed with EAX equal to 0. If the processor is not genuine Intel, the feature identification flags may have different meanings than are described in Intel documentation."

AMD ma "ciste nahodou" priznaky identifikujici SSE atd. na stejnym miste, takze kdyby se z toho generovanyho kodu odstranil ten test na Intel, tak to pobezi i na AMD, ale AMD ma preci vlastni specifikaci CPU, ktera preci nema s IA-32 nic spolecnyho. Intel tudiz nemuze garantovat, ze se AMD treba casem nezblazni a uplne specifikaci CPUID nezmeni. Navic Intel C++ je jen pro Intel CPU. Takze ve skutecnosti v generovanym kodu neni zadny kod, ktery by zamerne zdrzoval, je tam kod, kterej dovoluje, aby specializace bezela jen na Intelech, takze na AMD zbyde nespecializovanej kod (takze napr. bez vyuziti SSE, ...). To je nepochybne trosku svinarna ze strany Intelu (protoze ty priznaky jsou na stejnym miste), ale je to presne podle specifikaci OBOU vyrobcu. Tady se AMD trosku chytilo do vlastni pasti tim, ze vyrobilo vlastni architekturu AMD64, ale Intel C++ neni urcen pro tuto architekturu.

Doprcic, bez 10ti pripojeni ve Skype se fakt neobejdu...:D

>Bigkuba: tys to zrejme nepochopil, ten prekladac negeneruje kod ktery by byl optimalizovany pro intel a diky tomu o 10% rychlejsi, ale kod ktery na intelu bezi stejne rychle jako starsi verze, a na AMD o 10% pomaleji nez kod ze starsi verze kompilatoru.

Ostatne Skype se chova jako dobytek nejen selekci procesoru, video funkce na Skype 2.0 jsou omezeny na Windows XP, a pritom ve verzi skype 2.0 beta vpohode chodi i na windows 2000. Procpak asi, ze by nejaky ten dolar prihodil microsoft ?

Krizon> To souhlasi. Novejsi verze prekladace vic optimalizujou a snazi se vymacknout vykon co nejvic, takze jeste vic vyuzivaji scheduling apod. intelskejch CPU. Ten se samozrejme odlisuje od AMD. Starsi prekladace generovaly "hloupejsi" kod z pohledu IA-32, ktery je nahodou i kod vhodnejsi pro AMD. To presne souhlasi s tim, co cituje fikfik "...However, version 8.1 generates code that is much more dependent on the processor type...." Ano, pokud chci udelat lepsi optimalizaci, musim opravdu presne vedet, co mam za CPU.

Kto a ako sa vlasne dostal ku zdrojovemu kodu Skype? Ak sa nemylim, Skype nie je ziaden open-source, jeho kod nikdy nebol zverejneny...

bigkuba: precti si to jeste jednou - ta nova verze nic nezrychlila, o optimalizaci se nejedna! Pridano bylo _jenom_ to zpomaleni pro AMD.

Nedovedu si v praxi představit telefonování dvaceti lidí najednou. Ono někdy je problém se domluvit jen s jedním. I když jako možnost to působí impozantně, ne každý má takový telefon, aby mohl brebentit s celou partou, která sedí u piva v hospodě, zatímco on musí doma pod dozorem manželky potupně uklízet.

LOL... Fascinuje me, jak se v podobnych debatach ozyva stale dokola AMD rulez, Intel fuj, atpd. Boha... Vzdyt vam to AMD prece nikdo nebere :) Pokud vam tam vsechno bezi rychleji, spolehliveji a lacineji, tak budte radi. Ne kazdy ma podobne zkusenosti. Nebo se na podobnych debatach musite navzajem presvedcovat o tom, ze je AMD lepsi??

bigkuba:> kdyz si trak chtry, tak mi povez jak system pozna ktere virtualni jadro pripada n aktere fyzicke kdyz mas zapte HT u vicejadroveno intelu.

bigkuba: To nesouhlasí. Pokud by to bylo takhle (tj. postupně lepší optimalizace pro Intel procesory), tak by přece chování bylo toto: Kód kompilovaný novější verzí poběží na procesoru Intel rychleji než starší verzí, a na procesoru AMD poběží stejně rychle jako kód ze starší verze. Nicméně kód kompilovaný novější verzí běží na AMD procesorech POMALEJI než kód ze starší verze. To je řekl bych dost podezřelé

jaja: napis o co ti ide a potom sa pytaj. neviem naco je ta tvoja vrtajuca otazka dobra, alebo nedajboze mas nejake fakty? tak sem s nimi..

jaja> Preci z tabulek ACPI (treba SRAT=System Resources Affinity Table). Ale to jiste znas, takze nema cenu to tady rozvadet:)
gray_dust> Bud sem slepej nebo to nevidim;) Muzes, prosim, ocitovat tu pasaz, kde se tvrdi, ze kod kompilovany novejsi verzi je pomalejsi? Dekuji.

bigkuba: mas recht, z toho prispevku to vazne poznat nejde...tam se jen dozvis,ze na AMD stejny kod s novym kompilatorem bezi pomalejs,ale ani zminka o rozdilu stary vs. novy kompilator na Intelu.
all: uzavrel bych to jednoduse vetou: PRESTANTE POUZIVAT SKYPE!!! viz jeho praktiky obsazovani pasma pripojeni... nechtel bych ho ani za nic!

kdyz uz se nakousnul jinde, pise se o tomhle nekde na webu hulane ? Nemam silu procitat jeho clanky, ale na chvilku bych se chtel pobavit jeho vysvetlenim.

itokar> Dobre, a kde je zminka o tom, ze to poustel na IA-32? Tam by se (mozna) dockal zrychleni. Znovu opakuji, Intel C++ je prekladac pro IA-32.
MildaIV> Zdravim Mildu:) Ja neverim nicemu. Toto vse pouze jednoduse vyplyva z manualu k architekturam (jak IA-32 i AMD64) a z popisu produktu Intel C++ (pouze pro procesory IA-32). Oba architekturalni manualy jasne rikaji, ze pokud tam neni jejich "vendor ID" (GenuineIntel a AuthenticAMD), pak se na jakykoliv dalsi informace ziskane z CPUID nelze spolehnout. A opakuji po nekolikate: Intel C++ je prekladac pro IA-32, jasne to tam je napsany v jeho specifikaci a kazdej, kdo si ho koupi, tak to jasne vidi v manualu. No a pokud nekdo pouziva produkt k necemu, k cemu neni urcen, je to jeho problem, tj. pouzit prekladac Intel C++ pro preklad kodu pro AMD64 znamena, ze byl nespravne pouzit produkt, a pak Intel nenese zadny nasledky:)

"Oba architekturalni manualy jasne rikaji, ze pokud tam neni jejich "vendor ID" (GenuineIntel a AuthenticAMD"
A on snad na AMD není AuthenticAMD? Že ono to tam bude? Určitě ano.

Ostatně pokud chceš argumentovat, že Intel neví, jestli něco AMD nezmění. To je hodně slabý argument. To už taky Intel nemůže vědět, jestli číňani do nějakého svojeho procesoru nepřidají "Genuine Intel". Neměl by Intel, podle tvojí logiky, raději vypnout optimalizace i pro intel? I když opravdu nechápu, proč si Intel takovými hloupostmi, jako Skype pro 10 lidí, špiní jméno.

fotr> ??? Na AMD samozrejme je AuthenticAMD. Ale to nikdo v kodu netestuje:) Testuje se jen a pouze GenuineIntel, protoze Intel C++ je preci pro IA-32 a ty preci maji GenuineIntel. Uz jsem to psal: neni tam zadny kod, ktery by primo zpusoboval, ze AMD bezi pomaleji. Je tam kod, ktery zpusobuje, ze se na prislusnem Intelu pouzije rychlejsi kod.

fotr podruhe> Mam obavu, ze GenuineIntel jako SW identifikace CPU asi pujde patentovat nebo nejak jinak ochranit. Takze pokud to Cinani udelaji, muzou mit patentovej/ochrannej problem, na kterej oni se ale zvysoka vy... No nicmene i tak to nebude IA-32 procesor, ten pravej od "Mattela", takze pak zase pouzivas Intel C++, kde nemas.

fotr potreti> Jo a mas pravdu, nechapu, prov Intel takovy kraviny ted dela, kdyz ma na krku tu zalobu. Aniz bych nejak specialne branil Intel, klidne to taky mohlo byt tak, ze to proste bylo jen prelozeno Intelskym C++ a autor programu chtel dovolit vice uzivatelu, jen pokud je to "silnejsi" procesor (cili udelal specializaci pro dualy). Pak je ovsem podivne, ze se Intel se Skypem tvarili, ze je to technologii, jenze PR/marketing takovejchhle mamutich spolecnosti obcas zvladne i veci nevidane krasy:( Aby bylo jasno, pokud to tak skutecne bylo zamerne udelano/naprogramovano, tak je to nepochybne svinarna, za kterou si oba zaslouzi potrestat.

Intel FUJ.. howk dot point.. nehadze to na nich dobre svetlo.. asi im dochadza, ze im to vlastne dochadza ;P

vsem tem zastancum "AMD rulez" asi toto: intel je uz skoro prehistoricka firma a amd bylo kde, kdyz vybehlo pentium? ty kecy kdo komu co ukradl me tady fakt uz unavuji. kolik z vas uz neco vymyslelo, ze tady je kazdy odbornikem na vsechno? nepatrim mezi lidi co skacou od znacky ke znacce kvuli 5% vykonu navic v danem obdobi - vsazim na kvalitu uz pres 15 let --> takze jedine Itel. to ze pouzivam Intel je moje vec, a to co pouzivate vy je vase , presto se nepotrebuji snizovat k totalni stupidite hanenim konkurencni znacky. Uvedomte si, ze bez konkurence byste dneska meli leda tak kulickove pocitadlo. Takze tem inteligentnim panackum ala "amd rulez" jednu vec - nechte si ty kecy pro sebe.
PS: nejak sem moc nepostrehl tak ostre nazory na soft skype a jejich kod "boudu na zakaznika" jako na intel, prestoze je zde vicemene rec o skypu.
PS2: jedina rozumna reakce zde byla ta, kde kdosi uvedl, ze je mnohdy problem domluvit se z jednim - natoz potom z deseti.