Új hozzászólás Aktív témák
-
#25954560
törölt tag
Application Optimization Programming CodeBook egy rovidke guide.
-
dezz
nagyúr
A korábban emlegetett másolási ügyek margójára, mi volt legális és mi nem,stb.
"IBM PC and the x86 architecture
Main articles: Am286, Am386, Am486, and Am5x86
In February 1982, AMD signed a contract with Intel, becoming a licensed second-source manufacturer of 8086 and 8088 processors. IBM wanted to use the Intel 8088 in its IBM PC, but IBM's policy at the time was to require at least two sources for its chips. AMD later produced the Am286 under the same arrangement, but Intel canceled the agreement in 1986 and refused to convey technical details of the i386 part. AMD challenged Intel's decision to cancel the agreement and won in arbitration, but Intel disputed this decision. A long legal dispute followed, ending in 1994 when the Supreme Court of California sided with AMD. Subsequent legal disputes centered on whether AMD had legal rights to use derivatives of Intel's microcode. In the face of uncertainty, AMD was forced to develop clean room designed versions of Intel code.""AMD has a long history of litigation with former partner and x86 creator Intel.
- In 1986 Intel broke an agreement it had with AMD to allow them to produce Intel's micro-chips for IBM; AMD filed for arbitration in 1987 and the arbitrator decided in AMD's favor in 1992. Intel disputed this, and the case ended up in the Supreme Court of California. In 1994, that court upheld the arbitrator's decision and awarded damages for breach of contract.
- In 1990, Intel brought a copyright infringement action alleging illegal use of its 287 microcode. The case ended in 1994 with a jury finding for AMD and its right to use Intel's microcode in its microprocessors through the 486 generation."Szóval, az amerikai Legfelsőbb Bíróság végzése szerint, tetszik-nem tetszik, az AMD legálisan járt el. (Mellesleg egy sor más cég is ugyanígy tett, különben a PC nem válhatott volna valóban szélesebb körben elérhető platformmá.)
Az Intelt viszont jogerősen elmarasztalták a versenyellenes piaci magatartásáért:
"- In 2005, following an investigation, the Japan Federal Trade Commission found Intel guilty on a number of violations. On June 27, 2005, AMD won an antitrust suit against Intel in Japan, and on the same day, AMD filed a broad antitrust complaint against Intel in the U.S. Federal District Court in Delaware. The complaint alleges systematic use of secret rebates, special discounts, threats, and other means used by Intel to lock AMD processors out of the global market. Since the start of this action, the court has issued subpoenas to major computer manufacturers including Acer, Dell, Lenovo, HP and Toshiba.
- In November 2009, Intel agreed to pay AMD $1.25bn and renew a five-year patent cross-licensing agreement as part of a deal to settle all outstanding legal disputes between them."Idézetek innen.
-
dezz
nagyúr
válasz
#32839680
#124
üzenetére
Nem biztos, hogy nem járt volna jobban a világ, ha különválasztják a gyártást a procitervezéssel és(/vagy akár egyszerűen csak) kötelezik, hogy másnak is vállaljanak bérgyártást. Mert hogy az illegális módszerekkel biztosított kvázi monopolhelyzetből származó rekordbevételekből bőven futotta a világelső gyártástechnológia kifejlesztésére.
-
#123
Tejes Pite
aktív tag
Tejes Pite
aktív tag
Fúú mi van itt!
OFF világbajnokság! ![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#122
Lomha 8V
addikt
Ivy.4.Ever
#12
Lomha 8V
addikt
válasz
Ivy.4.Ever
#12
üzenetére
Hát nézd meg, a Costa Concordia-n leejtettek egyet, aztán mi lett belőle...
-
#25954560
törölt tag
bizony. hosszu az ut, mig az ember eljut odaig h a minosegi munkara tudjon torekedni. neha egyszeruen nincs ra lehetoseged h ugy csinald, ahogy szerinted a legjobb. ugy kell, ahogy a leggyorsabban tesztelheto kodot csinalod. sajnos a cegeknel altalaban ilyen mutato nincs a koder ertekelesenel.
-
orbano
félisten
válasz
#25954560
#114
üzenetére
feasibilityre nem volt idő, egy tenderre készült a cucc, rekrod idő alatt. azóta a prototípus kész, működik, pilotokra berheljük, igazából eladható. de így van, jobb lenne újraírni, újra is lesz írva. amint valaki fizet érte
addig meg a prototípus agyonhekkelése (ami elképesztő méreteket öltött már most is, és kezdünk is szívni miatta). közhely, de ez van, a pénzügyi keretek igen erősen korlátot szabnak az iskolában tanult szoftvertechnológiai módszereknek -
BatchMan
senior tag
Ritka zaftos topic, messze jobb, mint a cikk alapján vártam.
Néhány általános gondolat:
Ebben a gazdasági környezetben az intel és az AMD is bevételt termel, melléktermékként procikat. Azt gyártják, amire kereslet van, annak műszaki értékétől függetlenül.
Bebizonyitották, hogyha nem lennének ilyen zsugoriak, a cucc 64x gyorsabban is mehetne. -
#25954560
törölt tag
talalomra draga is.
viszont megeri csinalni vmi feasibility study szeruseget. tehat kicsi befektetessel tesztkornyezetet osszerakni es azon dolgozni. a projektnek csak ezutan kene indulnia. szerintem.
ennek persze az a veszelye, hogy a prototipusbol lesz a termek. ami szinten hiba, mert az eddigi tapasztalat azt mutatja, hogy minosegi ugrast jelent ujrairni a kodot, ha a prototipus kesz van. csak sajnos ez oriasi luxus idoben. -
Fiery
veterán
Orulok, hogy ez is elokerult. Lam-lam, minden ceg egyforma, ahogy fentebb irtam. Lopnak, csalnak, hazudnak. Egyiknek se nezzuk el, mindegyiknel jegyezzuk meg. Es tenyleg jo lenne, ha a konkret elkovetoket is birosag ele citalnak, talan akkor kevesbe tortenhetne meg legkozelebb mas cegeknel ugyanaz.
-
Fiery
veterán
A legutolso atszervezesnel szerintem mindenkit kivagtak, aki egy kicsit is ertett a dolgokhoz
Oke, viccen kivul: persze, miert ne lehetne? De miert lenne ez erdekes? Ha most nincs ott senki, attol me'g anno AMD-nek hivtak a ceget, a masikat meg Intelnek, mint ahogy most is. Es miert kene osszekotni a regi idoket a jelennel? En nem kotom ossze, csak nem teszem zarojelbe a reg megtortent dolgokat, csupan arra hivatkozva, hogy reg volt. Ennyi erovel akkor tegyunk mindent zarojelbe minden cegnel, ami nem iden tortent -- ez is egyfajta hozzaallas lehetne, de akkor sok mindent nem ertenenk abbol, ami tortenik... Ha az Intelnel nem tesszuk zarojelbe az ICC-s dolgokat, az unfair piac befolyasolast, a benazast az IA-64-gyel, a NetBursttel es a MIC-kel, a lebogest az AMD64 kapcsan, a hosszas kinlodast az iGPU piacon, akkor a tobbi cegnel se felejtsuk el az osszes benazast, mocskos huzast, unfair lepest, csalast, amitast, ami volt epp az elmult X evben. Emlekezzunk mindenre, az jo dolog. -
Abu85
HÁZIGAZDA
Reverse engineeringet az Intel is csinált nem is olyan régen. El is indult egy per csak igen gyorsan, 2009. november 12-én megegyeztek az AMD-vel, hogy minden folyamatban lévő eljárást megszüntetnek egymás ellen, és az Intel licenceli a ATI-tól szerzett technológiákat, amire a jövőben építhetnek. Többek között a Fast Z Clear és Hierarchical Z hardveres technológiákat másolták le, amiket hivatalosan 2009. november 12-én licenceltek, az AMD valamikor novemberben adta át a technológia implementálásához szükséges dokumentációt, de 2010. január 7-én már meg is jelent rá a Clarkdale IGP-ben a támogatás. Durva last minute change lehetett.
Rengeteg dolgot elloptak még az AMD-től csak végül megegyeztek és betömték a szájukat 1 milliárd dollárral. Más esetben durva perek lettek volna itt. -
Fiery
veterán
"Ez rendben van, csak úgy tűnik, mintha a kezdeti, kalandos évek miatt örökre és végérvényesen megutáltad volna az AMD-t (hiába nem egyedüli másoló volt), aki attól kezdve már akármit is csinál, nem hozhatja ezt helyre."
Nekem nincs erzelmi kapcsolatom egyik ceggel se, sz'al nincs mit helyrehozni. Es ezek a cegek nem kamasz sracok, hogy azt lehessen mondani a bolti lopasaikra 20 evre ra, hogy "kalandos kamaszkoruk volt". Ezek cegek, jol szervezett "bandak", amik elore megfontolt szandekkal kovetik el azt, amit csinalnak, es nem egyszeru botlasokat csinalnak, mint a gyerekek. Komoly, meglett, felnott emberek a donteshozoik, akik kitalaltak, hogy lopni kell az IP-t mastol. Es azok is komoly, felnott emberek voltak, akik konkretan darabokra szedték es lenyegeben tranzisztoronkent lemasoltak az Intel CPU-it (reverse engineering).
Egyebkent meg, en olyan fajta vagyok, hogy nehezen felejtek. Nem feltetlenul hozom osszefuggesbe egy ceg jelenlegi poziciojat a regi viselt dolgaival, de nem is teszem zarojelbe a viselt dolgokat. Es nem probalok felmenteni egy ceget sem a lopas alol azzal, hogy akkor az volt a "divat", meg hogy "anelkul hol tartanank most", meg hogy "ettol elerhetobbek/olcsobbak lettek az x86 PC-k". Nullarol egy CPU-dizajn letrehozasa nem egyszeru feladat, nem olcso, es aki ezt megteszi, annak az eladasi araba is be kell epitenie ezeket az R&D koltsegeket. Ha egy masik ceg ellopja az R&D eredmenyet, es sajatjakent arulja, akkor nyilvan megsporolja az R&D koltsegeinek nagy reszet, es olcsobban tudja arulni a vegtermeket -- megjegyzem, ezzel torzitja a piaci versenyt is, es unfair elonyhoz jut. Pont emiatt -- meg mert az IP letrehozasaval kapcsolatban van nemi tapasztalatom -- nem tartom bocsanatos bunnek a(z IP) lopast. A vicc az egeszben az, hogy nem cegek, hanem adott emberek (ceges alkalmazottak) kovetik el az ilyet, az USA-ban viszont valahogy megsem divat a konkret embereket Btk alapjan megvadolni, es lecsukatni a francba. Ehelyett a ceget rangatjak birosag ele patent infringement es hasonlo vadakkal, aminek a vege szinte mindig peren kivuli megegyezes, azaz se a bunt elkoveto ceget, se a bunt elkoveto alkalmazottakat, se a felbujtokent szereplo fonokeiket nem eri a vegen buntetes tulajdonkeppen. Persze kell csengetni nemi $$-t a megkarositott cegnek, de ennyivel siman megusszak. Ez rohej SZVSZ.
-
Sorkizártan szebben mutatna a cikk.
Egyre nagyobb teljesítmény, egyre rosszabb kódokkal. Én értem, hogy az Intel mindenkit ki akar zárni a piacról, de gyakorlatilag elfelejtett körbenézni. Nem tudom, van-e ezeknek a rendszereknek jövője.
AZ x86-tal megcélozták az egyre nagyobb teljesítményt, mely odáig jutott, hogy a szoftverek jelentősen lemaradtak. Ez részben pontosan annak köszönhető, hogy a legszutyokabb kód is gond nélkül fog futni az erőtartalék miatt. Az erőtartalék pedig egyre nagyobb, a kód egyre rosszabb lehet. Ma ez a tendencia.
Megjelentek a kis fogyasztású rendszerek, hamar kiderült, hogy ott ez nem működhet. Az ARM ezen felmászott, mobil eszközökben és beágyazott rendszerekben mára szinte egyeduralkodó. Az Intel egyre keskenyebb pallón egyensúlyoz, a PC-k sorsa kérdéses, és nem biztos hogy a szerverekben sokáig marad.
Ugyanakkor mi látszódik újra kirajzolódni? Bár az Android önmagában is egy overheades szemétdomb, de az elején kénytelenek voltak keményen odafigyelni az erőforrásokra. Mára már erőteljes az ARM architektúra is, egyre nagyobb a pocsékolás. Szinte ugyanazt (vagy alig több) az élményt kapod 10x erősebb rendszeren. Mert nem akarnak, vagy nem kell optimalizálni (OpenCL teljes elutasítása, pl.). A telefon közben ugyanúgy lemerül 1 nap alatt.
Ami a lényeg, nem erősebb processzorokra lenne szükség, hanem sokkal jobb szoftverekre. A programozás 5-10 évvel a hardver mögött van.
-
Fiery
veterán
Szerintem meg nem azonos a vas, hanem egy butabb, bar az IVB-n alapulo EU-bol pakoltak be 4 db-ot a Bay Trail-be. Ha tobb idom lenne molyolni ezzel (meg ha az OpenCL compiler nem benazna allandoan), akkor kimérném tobbfele utasitassal is a Bay Trail ateresztokepesseget. Nem lennék meglepodve, ha osztasnal, trigonometrikus fuggvenyeknel is hasonloan belassulna az IVB-hez kepest.
-
dezz
nagyúr
Az egy dolog, hogy az egyik nagyobb bűn, mint a másik, viszont az elsőt kb. mindenki csinálta.
Nyilván a Cyrix, NexGen, stb. is."A gyartok az ISA es architekturalis fejleszteseket mindig a megjelenes elott publikaljak."
Egy ISA egyszerű támogatása nem egyezik meg annak optimális kihasználásával.
"netan a fo modul maga."
Az még kényelmetlenebb, ha nem egyes DLL-ek között kell procitól függően választani, hanem a főprogram van többféle fordítóval fordítva.
"akkor az AMD64-et is le tudta volna "nullazni" az Intel."
Ha az nem jött volna ki jóval korábban, miközben az Intel eleve inkább az IA64-et propagálta, minek következtében a MS már nekiállt implementálni a támogatást (részben talán mert addigra a Linux is támogatta), bizonyosan sikerült volna rábírnia őket az Intelnek, hogy inkább az ő (amúgy utólag, sebtiben összecsapott) megoldását támogassa.
(#98): Ez rendben van, csak úgy tűnik, mintha a kezdeti, kalandos évek miatt örökre és végérvényesen megutáltad volna az AMD-t (hiába nem egyedüli másoló volt), aki attól kezdve már akármit is csinál, nem hozhatja ezt helyre.
-
Abu85
HÁZIGAZDA
Akkor szvsz valami szoftveres para lesz. Az IGP elvileg ugyanaz az architektúra, ami van az Ivy-ben. Csak hozzátették még az ETC-t és az ETC2, illetve az EAC kiegészítést. Ha nem tiltanak benne semmit, akkor az egyetlen dolog, ami gondot jelenthet az a belső buszrendszer. Mivel csak négy EU-t használnak, így nyilván szűkítettek rajta. Lehet, hogy túlszűkítették, vagy csak úgy tervezték, hogy grafikára jó legyen a többi meg csak menjen ahogy tud, de ott a sebesség nem érdekes. Ez még reális lehet, ha nagyon szűk volt a tranyóbudget.
-
Fiery
veterán
Atom Z3770, Intel Bay Trail B2 Reference Tablet. Dual Channel DDR3-1066. Siman tamogat OpenCL-t, nem mi eroltettuk ra
Persze lehet, hogy nem hivatalos az OpenCL tamogatas, es nem is kene nezni az ertekeket. De nem hiszem, hogy igy lenne, mert az inteles kontaktunk, amikor ezt a furcsagot megirtuk neki, elkerte a teszt app-ot, hogy megnezzek maguknak. Nem hajtott el egybol, hogy nem is tamogat OpenCL-t a platform. Pedig amugy eleg jo elhajtasban, pl. a 64 bites Windows + Bay Trail-T temakorre se tudtuk kicsikarni belole, hogy mondja meg, mikepp lehetne felvadaszni a tabletre egy _barmilyen_ 64 bites Windowst Csak kototte az ebet a karohoz, hogy varjunk par honapot, es majd jon egy Win8.1 javitas, amivel felrakhato lesz a 64 bites Win8.1 a tabletra.Az is lehet, hogy a Bay Trail-D/I/M variansok teljes erteku iGPU-val lesznek szerelve, de en az eddigiek alapjan nem tartom valoszinunek. Hamarosan kiderul.
-
Abu85
HÁZIGAZDA
Aranyos.
Egyébként ez mobil Bay Trail? Tudtommal az Intel csak a Bay Trail Pentium és Celeron esetében szállít majd OpenCL-t. Legalábbis hivatalosan azt mondták nekem, hogy az Atom mobil termékeket OpenCL nélkül szállítják. Ettől elvileg működhet, de gyanús, hogy az URB nagy részét letiltják, ami meg kivégzi az OpenCL teljesítményt.
-
Fiery
veterán
IVB-GT2 MAD @ 1150 MHz: 269.9 GFLOPS
IVB-GT2 ADD @ 1150 MHz: 146.9 GFLOPS
IVB-GT2 MUL @ 1150 MHz: 146.9 GFLOPSBYT MAD @ 311 MHz: 8.63 GFLOPS
BYT ADD @ 311 MHz: 9.97 GFLOPS
BYT MUL @ 311 MHz: 9.97 GFLOPSNeked gondolom nem kell magyarazni, hogy itt valami nem stimmel
Egyebkent SP floating-point termeszetesen, mast nem tudnak a nyomoronc Intel iGPU-k -
Fiery
veterán
Ha megnezed, amiket szoktam postolni, az alapjan szerintem eleg egyertelmu, hogy erzelmileg egyik ceggel sem tudok azonosulni, es inkabb azzal kavarom fel a vizet, hogy egyiket vagy masikat kritizalom. Persze amikor epp nem az egyiket kritizalom, akkor jonnek a masik hivei, hogy miert nem kritizalom az egyiket. Hidd el, en mindegyik ceget utalom valahol, es baromira nem csipem egyiket se, mert mindegyik miatt szivnom kell nap mint nap. Az utobbi par napban pl. felvaltva szivok az alabbi problemakkal:
1) A Google altal gyartott DLL bugja miatt a mi szoftverunk nem mukodik megfeleloen, es a Google megprobalta ranktolni a felelosseget. Egeszen addig, amig konkret videofelvetellel es specialis debug verzioval nem bizonyitottam, hogy a hiba nem a mi rendszerunkben van. Innentol nem rajongok a Google-ert
2) A Microsoft tovabbra sem (hetek ota) kepes a rendszerukben kijavitani egy bugot, ami miatt nem mukodik a Program Compatibility Assistant rendesen a v3.20 elotti AIDA64-ekkel. Innentol utalom a Microsoftot is.
3) A GPGPU Benchmark modulba be szerettem volna rakni egy MUL (szorzasi) es ADD (osszeadasi) altesztet is, a meglevo FLOPS es IOPS tesztek mellé. Addig tok jo volt a koncepcio, amig csak nVIDIA GPU-n probalgattam, addig hibatlan volt. Aztan megneztem AMD-n (Hawaii, Kabini), ahol az OpenCL compiler osszeszakadt a kerneltol. Innentol utalom az AMD-t. Aztan jott Intelen (Ivy Bridge, Haswell, Bay Trail), ahol az OpenCL compiler elszallt hibaval, valamint lefagyott, felvaltva. Most mar az Intelt is utalom. Persze mindket cegnek elkuldtem a bug reportot, nehany het vagy honap leforgasa alatt javitjak. Az AMD az elozo lejelentett OpenCL compiler bugot mar javitotta, az Intel még az elozo jelentett bugot sem javitotta. Melyiket utaljam jobban?
Miattuk nem tudjuk implementalni a megalmodott ADD es MUL alteszteket rendesen, amig nem javitjak a nyomorult compilereiket.Mi egyebkent azonnal jelentjuk a stikliket a megfelelo helyeken. (Tobbek kozt) mi inditottuk el azt is, hogy a Hawaii DP computing teljesitmenye korlatozva van negyedére; most meg a Bay Trail computing teljesitmenye korul talaltunk egy rendkivul gyanus dolgot, amirol mar beszelgetunk nehany szakmabelivel, hamarosan lejohet a mediaban is a dolog. Igen, ennyire utalom az AMD-t es az Intelt is, borogatom a biliket mindket oldalra, egyforman
-
Abu85
HÁZIGAZDA
Az MS-sel az AMD sok dolgot fejleszt együtt. PC-s szinten a C++AMP-t már részben az AMD fejleszti. Persze magát a rendszert az MS építi fel, teszteli ki, fogadtatja el, de zömében azokra az iránymutatásokra építenek, amiket az AMD hardveres részlege közöl velük.
Eredetileg ugye az AMD felelt volna a cross platform támogatásért, de végül az MS kiterjesztette a projektet, így az egész megváltozott. A cross platform támogatás feladatát az Intel vette át (LLVM/Clang), míg az AMD feladata az lett, hogy kijelöljék a C++AMP fejlődési irányait és elsőként fejlesszenek hozzá hardvereket. Ma úgy áll a C++AMP helyzete, hogy az AMD megmondja mi lesz a jövő, az MS ennek megfelelően fejleszt, míg az Intel a kész rendszernél arról gondoskodik, hogy az elérhető legyen nem Windows operációs rendszeren is. -
Fiery
veterán
"Szerinted más gyártók nem fejtették vissza a többiek chipjeit? Dehogynem."
A visszafejtes (reverse-engineering) sem legalis, de az alapjan egy azonos termek piacra dobasa még nagyobb bun.
"A piacra kerüléssel egy időben?"
Valamivel elotte is. A gyartok az ISA es architekturalis fejleszteseket mindig a megjelenes elott publikaljak. Nezd meg pl., hogy az Intel mennyivel a Sandy Bridge megjelenese elott publikalta az AVX specifikaciot, vagy most az AVX-512 speckot. Az AMD is ugyanigy tesz. Ugyanigy, a processzorok architekturalis fejleszteseirol is idoben beszamolnak a gyartok, hogy a compiler keszitok is fel tudjanak keszulni az uj vasakra. Ha nem igy lenne, kapasbol a GCC fejlesztok mar reg zugolodnanak
"Így az SSE(x)/AVX(x) optimalizált változatból is több kellene. Biztos nagyon örülnének neki a programozók..."
A programozok vagy lustak (vagy nincs idejuk ra), es nem erdekli oket ilyen szinten a dolog, csak menjen a forditott szoftver, a teljesitmeny masodlagos. Vagy odafigyelnek a teljesitmenyre, akkor meg ha kozos kodbazisbol dolgozhatnanak, nem lenne nagy kaland egy-egy performance orientalt modult tobb forditoval is leforditani. Ugyanezt kell tenni akkor is, ha mondjuk van nativ 32 bites es nativ 64 bites DLL is a szoftver reszekent, netan a fo modul maga.
A gond mindig akkor kezdodik, ha kulonbozo source kell az optimalizalt verziohoz meg a "simahoz". Ez az egyik problema az OpenCL-szeru megoldasokkal is: teljesen mas kodbazis kell a nativ, OpenCL nelkuli kodhoz, mint az OpenCL-en futohoz. Ha ezt megsporolod, mindjart konnyebb az elet.
"Nem tudhatjuk, hogy próbálkozott-e ezzel - csak nem hagyta az Intel."
Ha az Intelnek olyan nagy rahatasa lenne a Microsoftra (mar ha arra a megjegyzesemre gondoltal), akkor az AMD64-et is le tudta volna "nullazni" az Intel. A Microsoft nagyon eros ceg, ot nem lehet csak ugy ide-oda pakolni.
-
falco1
tag
Tökéletesen egyetértek mindennel, amit az utolsó 2 posztodban megosztottál.
Remélem nem túl bátor kijelentés az, hogy álláspontjaink közeledtek.Én csak azért szóltam hozzá a témához, mert a Te kezdeti álláspontod "A minden rendben ezzel" attitűdöt sugallta, morális felmentéssel együtt.
Szerintem abban egyet lehet érteni, hogy semmilyen cég apologétájának nem szabad felcsapni, nem kell és nem érdemes egy céggel érzelmileg azonosulni (sem AMD, Intel, Apple stb.). Viszont univerzális lehet az a maxima, hogy mindegyik cég balhés gyakorlatát érdemes kritizálni, és felhívni a figyelmet a stiklikre, főleg olyan szakmai berkekben elismert arcoknak, mint Te. Maximum nem változik semmi, de ha kikerekedik a balhé, esetleg még a felhasználók által kívánatos irányba is módosulhat a gyakorlat. (Az Intel compiler stiklik nagyobb nyilvánosság elé kerülése is egy tech site cikke alapján indult, amelyik történetesen VIA proci vendor string állítgatásával játszott)Kedves Fiery, köszönöm az interjút
Üdvözlettel:
Bacskó Zoltán
Falcosoft -
orbano
félisten
válasz
#25954560
#92
üzenetére
találomra választani egy architektúrát nagyon drága mulatság
persze valószínűleg ez lesz, egyelőre a megérzésem azt sugallja, hogy a HSA felé mozdulunk és kivárjuk a Kaverit. Addig meg veszünk egy 24 magos xeon WS-t, aztán fut azon, ahogy tud... mondjuk a Larrabee nagyon piszkálja a csőrömet, de arra még úgyis várni kell. Az x86 meg marad, mert könt minket, hogy desktop gépre kell programot írnunk, ráadásul a windoz is követelmény -
dezz
nagyúr
Az Am386SX and Am386DX piacra dobását évekkel késleltették. A 486-ossal kapcsolatban ment a jogi huza-vona, míg végül '95-ben megkapta az AMD a vonatkozó licenceket és immár (újra) legálisan gyárhatta a saját változatát.
"Biztos igazad van, hiszen mennyivel nehezebb egy joval egyszerubb architekturat fejleszteni, mint egy joval bonyolultabbat"
Csak a lényeget hagytad ki: "Mert ott már az eredeti is sokkal bonyolultabb chip volt, nem annyira strict környezeti feltételekkel az akkori elektronika szintjén." A kezdetlegesebb prociknál sokminden a ciklusszámok tekintetében is meghatározott volt, esetenként nem csak HW, hanem SW szinten is. Ahogy egyre bonyolultabbá váltak a procik, egyre rugalmasabbb lett a környezettel való kommunikáció.
"Rengeteget tanultak abbol, ahogy az Intel tervezte es gyartotta a CPU-it."
Szerinted más gyártók nem fejtették vissza a többiek chipjeit? Dehogynem.
"Megjegyzem, en eleg kozelrol ismerek olyan embert, aki mindharom jelenlegi CPU-gyartora tud 99-100% koruli szintre kioptimalizalt x86/x64/3DNow!/SSE/AVX/FMA assembly kodot gyartani, es sosem dolgozott az emlitett cegeknel."
A piacra kerüléssel egy időben?
"vagy DLL formaban, vagy EXE binariskent letezett pl. SSE optimalizalt verzio, meg "sima" altalanos x86 valtozat."
Így az SSE(x)/AVX(x) optimalizált változatból is több kellene. Biztos nagyon örülnének neki a programozók...
"csak a birosagi procedurak hatasara nem keszulhetett el, igaz?"
Nem azok hatására, hanem általánosságban a túl kicsi bevételek miatt, amit az Intel "intézett" (illegálisan).
ps. célszerű lenne, ha nem egy mondatonként reagálnál az egyes bekezdésekre, miköznen a mondatok egymásból következnek, hanem egészben. Hacsak nem akarod készakarva a lehető legjobban szétoffolni a topikot.
(#91): Nem tudhatjuk, hogy próbálkozott-e ezzel - csak nem hagyta az Intel.
-
#25954560
törölt tag
monthatnam h nyilvan eloszor a legjobb algoritmust kell megtalalni, de ez van a cikkben is
a vegen linkelt intel-fele utmutato termeszetesen akkor igazi segitseg, ha x86(_64)-en fogtok futni.a kod altal hasznalt adatmennyiseg pl ad egy tampontot. tehat ha pl tudod h 24M L3 cache-ed van (per socket), akkor pl erdemes torekedni arra, hogy lehetoleg az osszes adat beferjen es ne szemeteld ossze. oriasi ugras. aztan ha sok memoriat esztek, akkor muszaj figyelni a NUMA alignmentre, ne hozd be feleslegesen a QPI busz keslelteteset, de ez is nyilvanvalo
lehet h en kirpobalnam visszefele: valasztotok egy architekturat es megnezitek h nagysagrendileg mit birtok rajta. ha eleg, akkor lehet arrafele menni es ott tovabbfinomitani.
-
Fiery
veterán
Abbol meg az lesz, hogy a ceg hazudik, terel, mennek a birosagra panaszkodni, es vegul valahogy lezarul a tortenet. Az AMD ebbol tanulhatna, es csinalhatna vegre egy jobb forditot a sajat termekeire, vagy osszefoghatna az MS-sel peldaul. Megtortent? Me'g nem, legalabbis en nem tudok rola. Na most ez alapjan a kovetkezo lepes az, hogy a fejleszto menjen az AMD-hez panaszkodni, hogy csinaljon jobb forditot
Nem fognak, mert most mar a HSA-val foglalkoznak inkabb. -
Fiery
veterán
Me'g egy jo pelda a ceges hazugsagokra: ha pl. 2006-ban megkerdeztel volna nehany veletlenszeruen kivalasztott Apple alkalmazottat, hogy fejleszt-e az Apple mobiltelefont, akkor mindenkitol azt a valaszt kaptad volna, hogy nem. Ennek is 2 oka lehetett: vagy mert az illeto nem a vezetosegben es az iPhone-team-ben dolgozott, es o tenyleg ugy tudta, hogy nem fejlesztenek semmifele telefont az Apple-nel; vagy benne volt abban a korben, akik tudtak rola, de akkor meg nem mondhatta el. Dontsd el egy ilyen helyzetben, hogy hazudik-e az illeto, vagy csak nincs kepben
Raadasul, me'g ha hazudik is direktben, az is a ceg erdekeit szolgalja, hogy ido elott ne szivarogjon ki info az uj termekrol. Nem egyszeru dolgok ezek az ilyen cegeknel... -
Fiery
veterán
Az Intel is hazudik, az AMD is hazudik, a VIA is hazudik, mindenki hazudik. Nem jo dolog, de ennek 2 oka szokott lenni altalaban:
1) Vagy a ceg szerkezetebol adodoan nem tudnak egymas dolgairol az egyes egysegek dolgozoi, es tudatlansagbol mond baromsagot az illeto, pedig amugy nem akar hazudni.
2) Vagy felsobb utasitasra kell ilyen bulls***et nyomatniuk, nem tehetnek mast, ok csak kis fogaskerekek a nagy gepezetben. Ha elmondanak az igazsagot, ki lennenek rugva ipari titkok kiteregetese miatt, es azutan mas technologiai ceghez se vennék fel oket.
Nem akarom sem a felsobb vezetest, sem az egyszeru dolgozokat felmenteni, ne erts felre. De mar nekunk is szamtalan alkalommal hazudtak a technologiai cegek. A legutoljara az egyikuket megkerdeztuk, hogy mikepp lehet egy GPU-rol eldonteni, hogy milyen computing korlatozasok vannak az adott SKU-ban. Direkt rakerdeztunk, hogy milyen memory-mapped GPU regiszter lehet erre alkalmas. Ez alapjan mar nagyjabol be lehet loni, hogy melyik cegrol beszelek
Azt a valaszt kaptuk egy feketeoves GPU engineer-juktol, hogy nincs olyan GPU regiszter, amivel ezt lehetne detektalni. Ennek ellenere van ilyen regiszter, a nevet, indexet es a leirasat is megkaptuk mas forrasbol kozben. Na most, az emberunk vagy hazudott, vagy hulye a munkajahoz, es azert nem tudta, hogy van ilyen regiszter (ez utobbit en mondjuk kizarnam, a ficko tenyleg nagyon erti a munkajat latszolag). Es mielott me'g valaki belem kot: ellenoriztuk a regisztert, es a regiszter tartalmakat kulonbozo SKU-kon, es a tartalom abszolut egybevag a regiszter leirasaval. A dolog, a computing kepessegek detektalasa mukodik, es tenyleg GPU regiszteren at lehet detektalni.Az SSE-s botrany kapcsan en amondo vagyok, valoszinuleg felsobb utasitasra voltak kenytelenek hazudni a mernokok. Ez van, sajnos. Jobb lenne, ha nem lenne ilyen, de a tul nyilt, tul simulekony, tul egyuttmukodo cegek meg nem feltetlenul lesznek sikeresek hosszutavon is
Sajnos elobb-utobb mindig jon egy nagy, torteto ceg, ami elsopri a kis-aranyos-cuki cegeket. Aztan lehet utalni a nagy ceget, ha valakinek ez jolesik -
Fiery
veterán
"A felhasználók nem használnak ICC-t, azt sem tudják mi az."
Nem mondtam, hogy az egyszeru PC felhasznaloknak barmi koze lenne az ICC-hez. Nyilvanvalo, hogy ha egy forditorol van szo, ahhoz leginkabb a fordito gyartojanak, az architekturahoz (x86) kotheto hardver gyartoknak, valamint a kodereknek van leginkabb kozuk, oket erdekli a tema egyaltalan.
"Ha az Intel publikálta volna a működést, akkor a fordítót használó, aki abban a hiszemben vette a az ICC-t , hogy így mindenki számára gyorsabb kódot ad ki a kezéből, fordított volna egyet nem csak AMD(!), hanem minden nem-Intel proci számára, és így nem érte volna hátrány a nem-Intel CPU -t használó felhasználókat."
Eleg naiv volt az a koder, aki azt gondolta, hogy az Intel C Compiler nevu termek nem-Intel processzorra is annyira szep, optimalizalt kodot fordit, mint Intel processzorra. Nem veletlen, hogy nem "x86 C Compiler" a neve az ICC-nek. Megjegyzem, fog a koder egy hex viewer-t, es rakeres egy-ket SSE utasitas opkodjara. Vagy betolti a forditott binarist IDA-ba, es plain text search egy-egy SSE utasitasra. Mindezt megtettek idoben a koderek, hogy ellenorizzek az ICC altal forditott kodot? Nem. Felteteleztek valamit, amire semmi alapjuk nem volt.
"Pont ezt hangsúlyoztam, hogy azzal nem lett volna gond, ha az Intel compiler kimenete csak Intelen ment volna (a Te eredeti autós hasonlatod), mert akkor explicite lehetett volna tudni, hogy ha ezt a compilert használod, akkor nem Intel tulajok felé egy másik fordítóval fordított binárist is tessék mellékelni."
Abban egyetertek, hogy egyszerubb lett volna mindenki szamara, ha az ICC altal forditott kod nem futott volna mason, mint Intel CPU-n. De a koderek akkor is kiborultak volna, ha az ICC kimenete elhajtotta volna oket egy "No Intel CPU, no compiling" uzenettel. "No GUS, no demo" -- emlekszik me'g erre valaki itt?
"És igen ez bünteti a VIA-t és minden nem Intel CPU-t is, úgyhogy ezt a attitűdöt nem lehet azzal az érvvel alátámasztani, hogy az AMD meg micsoda bűnöket követett el."
Az egyik egy unfair huzas volt (ICC), a masik meg buncselekmeny (IP-lopas). Tegyek a ketto koze relacios jelet? En egyebkent sosem mondtam, hogy az Intelt felmentem barmi alol. Csupan azt, hogy megertem, hogy miert csinaltak. De en inkabb azt csinaltam volna, hogy ne is menjen az ICC kimenete nem-Intel CPU-n, ugy egyszerubb, tisztabb lett volna. Nyilvan az Intelnek meg volt ra a jo oka, hogy nem igy tett.
"A felhasználó nem tudja, hogy mi az az ICC-vel fordított szoftver."
Akkor panaszkodjon a szoftver fejlesztojenek, hogy nem eleg jol fut a szoftver az o processzoran. A szoftver fejlesztoje meg panaszkodjon a compiler fejlesztojenel. Nem olyan bonyolult ez.
"Egyébként nem gondolom, hogy Te tényleg szívesen vizionálsz egy olyan x86 világot, ahol annyiféle binárist kéne fordítani egyetlen programhoz, ahány CPU vendor létezik a palettán."
3 fele binaris nem nagy kaland, amennyiben a source azonos lehet.
"A vendor tudatos compiler nem egy jó ötlet."
Pont az ellenkezoje lenne a jo megoldas szerintem is. Minden gyarto fejlesszen sajat compilert, de azonos source-bol tudjon dolgozni az ember.
-
orbano
félisten
válasz
#25954560
#78
üzenetére
mondjuk én ezeket szeretem már a fejlesztés utánra kitolni. jellemzően a kód egy kisebb töredéke jelenti a szűk keresztmetszetet, az is sokszor olyan kód, amire az ember elsőre nem gondol, csak elemzés után. persze ilyen alap dolgok nekem is az ujjaimban vannak, hogy ciklusban ++i-vel inkrementálok, mindig írok else ágat, stb. De azért ezek sajnos nem váltják meg a világot, amikor visszalépéses algoritmust kell írnod 15 helyiértékre, ami egy (minimum) köbös algoritmus magjában fut.
amióta egyébként ilyen programokat írok C#-ban, rászoktam, hogy nagyívben teszek mindenféle kódoptimalizálásra. Első körben mindig algoritmus/adatszerkezet szinten próbálunk gyorsítani, tehát még magát az absztrakt programot alakítjuk. Ha az már stabil, és kvázi kész terméknek tekinthető, akkor profilerrel megvizsgáljuk és gyorsítjuk, ahol csak lehet. Ha elfogytak a szűk keresztmetszetek, akkor megint lehet gondolkodni az átalakításon. Aztán ezt szépen lehet ismételni egy párszor, amíg van az embernek ötlete A baj csak eztán jön, amikor már minden klappol és az egészet meg kéne írni C-ben, de ugye architektúrát kellene választani. Nekem speciel most még fingom sincs, hogy mondjuk egy Kaveri procis gépekből álló tömböt, Larrabeet, GPU-t, vagy valami mást válasszunk. Arra meg találj embert, aki megadja a választ Lehet az lesz, hogy elmegy majd fél évem rá, hogy megismerjem ezeket az architektúrákat, döntsek, aztán keressek egy jó szakit az átírásra. -
falco1
tag
"When I started testing Intel's compiler several years ago, I soon found out that it had a biased CPU dispatcher. Back in January 2007 I complained to Intel about the unfair CPU dispatcher. I had a long correspondence with Intel engineers about the issue, where they kept denying the problem and I kept providing more evidence. They said that:
The CPU dispatch, coupled with optimizations, is designed to optimize performance across Intel and AMD processors to give the best results. This is clearly our goal and with one exception we believe we are there now. The one exception is that our 9.x compilers do not support SSE3 on AMD processors because of the timing of the release of AMD processors vs. our compiler (our compiler was developed before AMD supported SSE3). The future 10.x compilers, which enter beta this quarter and release around the middle of the year, will address this now that we�ve had time to tune and adjust to the new AMD processors.
Sounds nice, but the truth is that the CPU dispatcher didn't support SSE or SSE2 or any higher SSE in AMD processors and still doesn't today (Intel compiler version 11.1.054). I have later found out that others have made similar complaints to Intel and got similarly useless answers (link link). "
És azért még ezt is megkérdezném tőled:
Ezzel is minden rendben van? Mármint, hogy simán az arcodba hazudnak, ez is befér még nálad az "ügyes" kategóriába?
-
Fiery
veterán
"Szét is csapott, hiszen egyik-másik korai x86 chip pont a jogi huzavonák miatt nem tudott sokáig megjelenni a piacon. Tehát a feltételezésed téves."
Miert lenne teves? Az Intel hamarabb es eroteljesebben szetcsaphatott volna a gyartok kozt, teljesen ellehetetlenitve azt, hogy eladjak a lopott IP-n alapulo termekeiket. Ha ezt addig csinalja, amig a gyartok vagy csodbe nem mennek, vagy nem csinalnak sajat CPU architekturat, akkor lehet, hogy csak 1-2 gyarto maradt volna az x86 porondon. Hogy az az AMD lehetett volna-e, mar sosem tudjuk meg
"Azt, hogy a korábbi chipeket szerintem ők sem tudták volna ott és akkor koppintás nélkül produkálni."
Biztos igazad van, hiszen mennyivel nehezebb egy joval egyszerubb architekturat fejleszteni, mint egy joval bonyolultabbat
808286 = 134 ezer tranzisztor, K5 = 4,3 millio tranzisztor. Aki az utobbit ki tudta fejleszteni sajat kutfobol (AMD), az 100%, hogy az elozot nem tudta volna Egyebkent ha a Pentium elotti Intel CPU-kat nem masolja le az AMD, es nehol nem fejleszti tovabb oket, akkor jo esellyel sose lett volna nullarol annyi tapasztalat a birtokaban, amivel a K5-ot osszehozhatta volna. Rengeteget tanultak abbol, ahogy az Intel tervezte es gyartotta a CPU-it. Ergo ha nem lopja el az Inteltol az IP-t, akkor talan sosem tudott volna K5-ot letrehozni. Akkor lehet, hogy a NexGen felvasarlasaig vergodtek volna. De ez csak az en teoriam...
"Nem hiszem, mert az Intel ismeri a legjobban a saját procijait."
Es? Az AMD ismeri legjobban a sajat procijait. Egy-egy. Megjegyzem, en eleg kozelrol ismerek olyan embert, aki mindharom jelenlegi CPU-gyartora tud 99-100% koruli szintre kioptimalizalt x86/x64/3DNow!/SSE/AVX/FMA assembly kodot gyartani, es sosem dolgozott az emlitett cegeknel. Mivel ilyen emberek leteznek, szuksegszeruen ez azt jelenti, hogy barki tudna igen-igen jo minosegu forditot fejleszteni barmelyik CPU architekturara. Csak sokba kerulne, idoben es penzben is.
"Az AMD legfeljebb a saját procijára tudna nagyon jól fordítani."
Az boven eleg lenne.
"De az irreális elvárás, hogy minden programot két-/többféle fordítóval fordítgassanak, majd Fat Binaryként terjesszék, mintha teljesen más ISA-ra épülne."
Miert ne lehetne, ha a source azonos? Nem egy olyan szoftver letezett par evvel ezelott (amikor utoljara ezeket nezegettem), aminel vagy DLL formaban, vagy EXE binariskent letezett pl. SSE optimalizalt verzio, meg "sima" altalanos x86 valtozat.
"Nem kis költség saját fordítót fejleszteni, amire az AMD-nek nem nagyon van pénze. Többek között az Intel hosszú évekig folytatott, világszerte több bírósági végzés szerint is illegális piaci praktikái miatt."
Hogyne, csak ez az oka, egyertelmu. Az elso ilyen birosagi eljaras megindulasa elott azert ugye az AMD elkezdte a fordito fejleszteset, csak a birosagi procedurak hatasara nem keszulhetett el, igaz?
-
falco1
tag
Szia,
"Miert kellene egyaltalan mukodnie mas termekeken a fordito eredmenyenek… Az nem problema, hogy az Opel navigacio frissitese nem mukodik Ford autokon es viszont? Miert gond ez a CPU vilagban?”
Ez a helyzetnek egy nagyon nem találó leírása...."Csakhogy legyen valamiféle konszenzus: Mivel erre a részre nem reagáltál úgy veszem ebben legalább egyetértünk már.
"Es az Intel soha nem szorgalmazta azt, hogy az ICC-t AMD vagy VIA procikhoz is hasznalja barki is -- vagy csak en nem emlekszem ilyesmire?"
Itt ismét ugyanaz az absztrakciós szint probléma van, ahol "Mármint szerintem" az érveid csúsznak.
A felhasználók nem használnak ICC-t, azt sem tudják mi az. Egy programot ugyanis nem azon a CPU-n használnak (kizárólag), amin fordítják. Ha az Intel publikálta volna a működést, akkor a fordítót használó, aki abban a hiszemben vette a az ICC-t , hogy így mindenki számára gyorsabb kódot ad ki a kezéből, fordított volna egyet nem csak AMD(!), hanem minden nem-Intel proci számára, és így nem érte volna hátrány a nem-Intel CPU -t használó felhasználókat. A fogyasztóvédelemnek mindenhol dolga, hogy az ilyen praktikákkal szemben védje a felhasználót.
Pont ezt hangsúlyoztam, hogy azzal nem lett volna gond, ha az Intel compiler kimenete csak Intelen ment volna (a Te eredeti autós hasonlatod), mert akkor explicite lehetett volna tudni, hogy ha ezt a compilert használod, akkor nem Intel tulajok felé egy másik fordítóval fordított binárist is tessék mellékelni.
Az Intel viszont azt egyáltalán nem akarta, hogy nem-Intel CPU -nál nyilvánvaló legyen a trükk. Az Intel érdeke pont az volt, hogy közös kódbázisssal fussanak a programok minden x86 CPU-n, csak az Intel legyen a nyerő, ha egyszer megnézed, hogy ezt milyen sebességgel teszik.
És igen ez bünteti a VIA-t és minden nem Intel CPU-t is, úgyhogy ezt a attitűdöt nem lehet azzal az érvvel alátámasztani, hogy az AMD meg micsoda bűnöket követett el.
"mert az AMD es a VIA nem kepes _sajat_ compilert kesziteni! Nem az Intel hibaja, hogy a tobbi gyarto lusta, es inkabb a konkurencia compilerere tamaszkodik. A felhasznalo meg vehet mas termeket is, semmi sem kotelezi egyik felhasznalot sem arra, hogy epp AMD, VIA (vagy Intel) termeket vasaroljon, es aztan azon ICC-vel forditott szoftvert hasznaljon. Van mas fordito, van mas CPU, lehet valogatni."
Ugyanaz, mint fentebb. A felhasználó nem tudja, hogy mi az az ICC-vel fordított szoftver.
Egyébként nem gondolom, hogy Te tényleg szívesen vizionálsz egy olyan x86 világot, ahol annyiféle binárist kéne fordítani egyetlen programhoz, ahány CPU vendor létezik a palettán.
A vendor tudatos compiler nem egy jó ötlet. A vendor szerinti CPU dispatchernek nem a compilerben, maximum a felhasználói programban van a helye (de a vendor független CPUID flagek használata még itt is preferált).
-
dezz
nagyúr
"Meg tudtak oldani kesobb is ezt. Socket 7-ben hanyfele architektura letezett? Kb. 10, rengeteg gyartoval, hadd ne soroljam fel mindet. Barmelyik sockethez lehet sokfele architekturat fejleszteni."
Az jóval később volt, másféle elektronikai környezetben, nem összehasonlítható. Az utolsó állítás szerintem nem állja meg a helyét.
"De azert a 486 mar eleg fejlett cucc volt."
A Motorolának és másoknak jobb procijai voltak, csak sajnos nem tudtak versenyezni az x86 PC-k áradatával.
"Gates irta azt, hogy "640KB should be enough for everyone"."
Ergo Gates egy bolod volt, akinek minden kijelentése hülyeség? Vedd észre, hogy az ott egy tényeken alapuló megállapítás volt.
"Az soha nem fert bele"
Sok elektronikai cég vett át megoldásokat akkoriban másoktól.
"Kesobb miert tudtak megoldani masolgatas nelkul?"
Mert ott már az eredeti is sokkal bonyolultabb chip volt, nem annyira strict környezeti feltételekkel az akkori elektronika szintjén.
"Nem csak az AMD, mas is megoldotta kesobb masolas nelkul. Rise, IDT, NexGen, Cyrix, Transmeta, stb."
Ez nem bizonyítja, hogy a korábbiakat is meg tudták volna oldani így, ott és akkor.
"Ha az Intel hamarabb szetcsap a gyartok kozt, akkor szerintem most nem lenne AMD."
Szét is csapott, hiszen egyik-másik korai x86 chip pont a jogi huzavonák miatt nem tudott sokáig megjelenni a piacon. Tehát a feltételezésed téves.
"Nemtom, ezzel mit akartal mondani. En csak azt mondtam, hogy mas cegek, az AMD-nel kisebbek, "ujabb fiuk" is tudtak uj architekturat tervezni, koppintas nelkul."
Azt, hogy a korábbi chipeket szerintem ők sem tudták volna ott és akkor koppintás nélkül produkálni.
"mar reg lenne rohadt jo AMD C fordito, ami le is korozhetne a konkurenseket."
Nem hiszem, mert az Intel ismeri a legjobban a saját procijait. Az AMD legfeljebb a saját procijára tudna nagyon jól fordítani. De az irreális elvárás, hogy minden programot két-/többféle fordítóval fordítgassanak, majd Fat Binaryként terjesszék, mintha teljesen más ISA-ra épülne.
"Es a slusszpoen: me'g egy ilyen szivas utan se all neki sajat forditot fejleszteni!"
Nem kis költség saját fordítót fejleszteni, amire az AMD-nek nem nagyon van pénze. Többek között az Intel hosszú évekig folytatott, világszerte több bírósági végzés szerint is illegális piaci praktikái miatt.
-
Fiery
veterán
A Cyrixnak nagyon erdekes kezdemenyezesei voltak, nemkulonben a NexGennek. Emlekszel peldaul a MediaGX-re? Nem ismeros az valahonnan?
A NexGent pedig pont az AMD vasarolta fel, az AMD nelkul NexGen Nx686 neven jelent volna meg a K6, es adott esetben ugyanolyan sikert tudott volna befutni, mint az AMD neve alatt. Ha az AMD kepessegeit is csupan a K5 alapjan mernenk fel (mint ahogy a Cyrixet mondjuk a 6x86 vagy az MII alapjan), akkor nyilvan nem lenne ilyen rozsas a kep Az AMD-nek volt lehetosege -- a NexGen felvasarlasa es a DEC-tol atjott mernokok segitsegevel --, hogy tovabblepjen, es kifejlesszen egymas utan egy csomo jo architekturat. K6, K7, K8, mind baromi jok voltak. A K10 is viszonylag jo volt. A K14 (Brazos) szinten jo volt (figyeled, csupa jo cuccot mondok az AMD kapcsan), a K12 (Llano) se volt rossz. Aztan jott a lejto Meg a Jaguar, ami megint baromi jo architektura. Nem masolt, sajat. Es jo. Tud az AMD, ha akar -- anno nem akart, hanem a konnyebbik utat valasztotta. Most akar es tud jo architekturat fejleszteni.Es hidd el, nincs zsigeri utalat bennem az AMD kapcsan. Rengeteg AMD CPU-m volt, az elso PC-m Am386SX alapu volt, utana volt Am486DX4, Am5x86, K5, K6-2, Duron, Athlon, es az elsok kozt volt kis hazankban Athlon 64-em is. Utana Opteron (Socket 940), Athlon 64 X2-bol 2 fele is. Utana jott az az idoszak, amikor mar nem voltak jobbak az AMD CPU-k, mint az Intel-felek, es akkor valtottam Intelre. Csupan azert, mert nekem a leggyorsabb CPU kellett, nem markaszeretetbol vagy nemszeretetbol. Ha pl. most a legjobb APU kellene, akkor AMD alapu gepem lenne megint.
Ugyhogy hidd el, nem utaltam sose az AMD-t, most se utalom oket vagy a termekeiket. Amit viszont utalok, az az IP ellopasa. Kis hazankban lenyegeben semmi tisztelete nincs az IP-nek, sajnos ez tarsadalmilag hianyzik legtobbunkbol. Talan az ennek az oka, hogy tulsagosan hozzaszoktatott minket az IP lopashoz az elozo rendszer, es hiaba van a Btk-ban, sz**ik ra szinte mindenki.
-
dezz
nagyúr
A Cyrix mennyivel volt jobb, mint az AMD? Mi akadályozta meg őket vagy a NexGent, hogy az AMD-nél jobb procikat készítsenek? Biztos vagy benne, hogy az AMD eltűnésével sikeresebbek lettek volna és nem szálltak volni ki ugyanúgy? Szerintem az AMD nélkül elhalt volna a PC vonal... Voltak jobbak.
De úgy látom, benned egy olyan zsigeri utálat van az AMD ellen, amit semmi sem képes már kitörölni.
-
#25954560
törölt tag
hogy egy kis ON is legyen
messze nem csak lelkiismereti kerdes az optimalizalas, ez tiszta sor. amit en, mint mezitlabas koder hozza tudok tenni a dologhoz ingyen vagy nagyonkeves munkaval az az, hogy mar eleve nullarol ugy irom a kodot, hogy az jo esellyel a leheto leghatekonyabb legyen a legegyszerubb szinten. gondolok itt arra, hogy pl
- case-ekbol legelore azt az agat tedd, ami legvaloszinubben fut le,
- segitsd pl az elagazas-becslest if-eknel likely/unlikely-val,
- adatstrukturakaidat ugy szervezd, hogy ne kelljen tul sokat shiftelgetni hogy hozzaferj valamihez
- vedd figyelembe a cache-lineok meretet es lehetoleg a leggyakrabban hasznalt cucc az elsoben legyen (ha nagy a strukturad)
- alignment
- cilusokat pl 0-ig futtasd ha lehet, mert a nullcheck olcsobb, mint az osszehasonlitas ket ertek kozott
stb.ezekhez nem kell felvenni senkit sok penzert
termeszetesen ezekkel csak picit lehet hozzajarulni , de ez az a szint, amivel ingyen elerheto.
es nagyon hasznos a gcc/icc kapcsoloit is nezegetni, verzionkent. amikor kijon egy uj fordito es vannak benne architektura-specifikus kapcsolok, akkor azok a kodtol fuggoen tudnak tobbet/kevesebbet segiteni.persze ennek is feltetele, hogy tudd legalabb azt, hogy mi a forditod. es egy kicsit azt is h mi az architekturad.
vagy ahogy mi is vagy Fiery-ek is csinaljak, a kritikus reszeket assembly-ben. ami ugye megint csak nehezites, de soxor megeri.
ha a ti esetetekben a legtobb fele vason futo leheto leghatekonyabb kodot kell irni, az lenyegesen nagyobb kihivas. en valoszinuleg ugy gondolkodnek h nagy vonalakban x86-ra egyfele csomag legyen, ARM-ra egy masik, Sparc-ra a harmadik, stb. leginkabb ti is a forditot tudjatok megtamogatni gondolom, de konretumot nem tudok mondani, mert a C#-hoz hulye vagyok
-
-
SylverR
senior tag
Jajjajj... Analógiának szántam.
69-től napjainkig, az 44 év. A 80-as évek elején volt ez a problémás időszak.
Egy ember nagyjából éljen 100 évet. 100 -> 44. Egy 20 éves ember, az nagyjából az emlitett időszakra esik.
Természetesen, ha hibázott, büntessék meg. De az ügy réges rég lezárult, hogy most jogosan, vagy sem, lényegtelen. Mi nem tudhatjuk pontosan.@Fiery: Oké. Sajnálom, hogy megmertem szólalni. Biztos igazad van. Rúgjuk föl a csúnya 90 éves bácsit, amiért 20 éve bűnt követett el! Sőt, égessük meg máglyán!
A fentebb irtakat neked is javaslom. Ne TE akard eldönteni, hogy kinek van igaza.
Természetesen megesett már a világban, hogy egy régi ügyet újra felhánytorgatnak, de illetlen, nevetséges és undoritó dolog. Egyszer már lezárták, felejtsük már el.És még valami: Nem Robin Hood. Én arról beszéltem, hogy készült konkurencia, ami olcsóbban kinálta majdnem ugyanazt... Én erről beszélek, hogy jót tett velünk. És nem csak az AMD, a Cyrix, meg a többi is.
-
Fiery
veterán
"Pin-compatibilisnek kellett lenni az eredetivel"
Rossz erv. Meg tudtak oldani kesobb is ezt. Socket 7-ben hanyfele architektura letezett? Kb. 10, rengeteg gyartoval, hadd ne soroljam fel mindet. Barmelyik sockethez lehet sokfele architekturat fejleszteni.
"Több más, nagy nevű vállalat is megtette (Texas Instruments, Harris/Intersil, Siemens). Nem beszélve a kisebbekről (Cyrix, VIA, stb.)."
Es akkor az felmenti az AMD-t? A Cyrix egyebkent a 486-os vonalbol mar sajat tervezesu CPU-val probalkozott, es TI markajelzes alatt is azt arultak. A VIA meg akkoriban me'g nem tervezett vagy arult CPU-t, csak kesobb, de ahhoz kellett az is, hogy felvasaroljak a Cyrixot majd az IDT-t.
"A korábbiakat nem tudom, de az Am5x86 nem 1:1 copy volt."
Persze hogy nem, mert az egy ellopott CPU-dizajn (486) tovabbfejlesztese volt. De attol, hogy lopott portekat becsomagolsz szep selyempapirba, az még nem lesz legalis.
"Mellesleg, mint írtam, ezek a kezdeti Intel procik nem voltak valami nagy világszám."
Nem allitottam az ellenkezojet. De azert a 486 mar eleg fejlett cucc volt.
"BTW, egy szösszenet az Intel 80286-osról"
Gates irta azt, hogy "640KB should be enough for everyone". Ja, es Ballmer azt nyilatkozta az iPhone-rol 2007-ben, hogy senki se fog ilyen draga telefont vasarolni. Szerintem tegyuk zarojelbe azt, amit a Microsofttol barki, barmikor nyilatkozik
"Egymás megoldásainak az átvétele is "belefért" akkoriban"
Az soha nem fert bele, legfeljebb csak addig, amig tul kicsiben focizott az, aki muvelte. Egy 2%-os piaci reszesedesu cegnek mast neznek el a "nagyok", mint egy 20 vagy 50%-osnak. Amikor valaki pimaszsagbol, csinytevesbol meggazdagszik, es elkezdi huzogatni a nagyfiuk szakallat, olyankor szokott egy **rva nagy sallert kapni
"Szükségszerű volt"
Nem volt az. Nem az eletuk mult rajta. Kesobb miert tudtak megoldani masolgatas nelkul? Nem csak az AMD, mas is megoldotta kesobb masolas nelkul. Rise, IDT, NexGen, Cyrix, Transmeta, stb.
"Nagyon egyoldalúan nézed, mert az AMD (először másokkal együtt, később egyedül) tulajdonképpen segítettek az x86 elterjesztésében és dominánssá tételében."
Pont ezert turte el a kicsiket az Intel. Egy darabig. Ha elobb szetcsap koztuk, akkor most lehet, hogy mar x86 se lenne, de az is lehet, hogy egy teljesen mas ceg lenne az Intellel egyutt az x86 piacon. Ha az Intel hamarabb szetcsap a gyartok kozt, akkor szerintem most nem lenne AMD. De az csak az en megerzesem.
"A NexGen első értékelhető chipje ugyanúgy a Pentium ellenfele volt és ugyanúgy saját uarc-ra épült, mint ahogy az AMD K5-öse. Kb. egy időben. A Transmeta kb. 5 évvel később lépett piacra termékkel."
Nemtom, ezzel mit akartal mondani. En csak azt mondtam, hogy mas cegek, az AMD-nel kisebbek, "ujabb fiuk" is tudtak uj architekturat tervezni, koppintas nelkul. Az meg, hogy ki mikor lep be egy piacra, nem lenyeges. Barmikor be lehet lepni, lasd pl. a Google (mondjuk az MS-hez es az Apple-hoz kepest) milyen keson lepett be az operacios rendszerek piacara, aztan hol tartanak.
"Az Intel volt a domináns fél és nyilván ők csinálták a legjobb fordítót a saját procijaikhoz, így a fordítók terén is domináltak. Más gyártó fordítóját akkor használták volna szélesebb körben, ha legalább ugyanolyan jó Intelben, miközben más procira is jól fordít. Elég "érdekes" elvárás..."
Ne haragudj, de barmikor el lehet kezdeni sajat forditot fejleszteni. Ha az AMD nem tamaszkodik az ICC-re meg a VC-re meg a GCC-re, hanem mondjuk a K5 vagy a K6 kornyeken nekiall forditot fejleszteni, mar reg lenne rohadt jo AMD C fordito, ami le is korozhetne a konkurenseket. Nem jo erveles az, hogy nehez lenyomni egy nagyon jo termeket -- ha mindenki igy gondolkozna, befagyna a piaci verseny egy adott ponton, nem mozdulna senki semerre. Lasd Tesla (az autogyarto) peldaul: barmikor be lehet lepni egy nagyon suru, nagyon durva technologiai piacra is sikeresen. Megjegyzem, az AMD csinalhatna pl. GCC forkot is, es ugy hamarabb meg lehetne a meloval.
Az meg plane gaz, ha valaki lustasagbol (es fokent penz sporolasbol) nem fejleszt sajat forditot, hanem masera tamaszkodik, aztan amikor a masiknak a termeke elkezd kibabralni a sajat termekevel, akkor meg rohan a birosagra rinyalni. Es a slusszpoen: me'g egy ilyen szivas utan se all neki sajat forditot fejleszteni!
-
dezz
nagyúr
"Akkor mar szabadon el lehet lopni masnak a CPU dizajnjat?"
1. Pin-compatibilisnek kellett lenni az eredetivel, és ezeknél a kezdetleges prociknál a kódvégrehajtásnak is nagyon-nagyon hasonlónak kellett lennie (utasítások latenciája, stb.), amit gyakorlatilag kivitelezhetetlen lett volna pusztán az ISA független és teljesen önálló implementálásával.
2. Több más, nagy nevű vállalat is megtette (Texas Instruments, Harris/Intersil, Siemens). Nem beszélve a kisebbekről (Cyrix, VIA, stb.).
3. Ha nem tették volna, az IBM PC/XT/AT vonalnak hamar vége szakadt volna a jóval olcsóbb PC klónok hiányában. Talán jobb is lett volna, voltak sokkal okosabban kitalált platformok. A többiek ki is koptak egy idő után, csak az AMD maradt, mint olcsóbb, de nem feltétlen rosszabb alternatíva. Ki tudja, hogy az AMD nélkül nem kerekedett-e volna felül az x86-on a 68k vagy a PowerPC.
4. A korábbiakat nem tudom, de az Am5x86 nem 1:1 copy volt. [link] [link]Mellesleg, mint írtam, ezek a kezdeti Intel procik nem voltak valami nagy világszám. Ha véletlenül nem rájuk esik az IBM választása, pár évvel később más sehol sem lett volna az x86 vonal, hiszen voltak sokkal jobb platformok.
BTW, egy szösszenet az Intel 80286-osról: "The problems led to Bill Gates famously referring to the 80286 as a "brain dead chip",[11] since it was clear that the new Microsoft Windows environment would not be able to run multiple MS-DOS applications with the 286. It was arguably responsible for the split between Microsoft and IBM, since IBM insisted that OS/2, originally a joint venture between IBM and Microsoft, would run on a 286 (and in text mode)."[link]
"Amugy meg szabadversenyes kapitalizmus volt akkoriban az USA-ban, a verseny lenyege a verseny, es nem az, hogy ajnarozzuk egymast."
Egymás megoldásainak az átvétele is "belefért" akkoriban.
"Abban az idoben, amikor az AMD masolgatta az Intel CPU-it"
1. Nem csak az AMD, lásd fent. 2. Szükségszerű volt, lásd fent.
"az x86 kapasbol nem volt me'g olyan dominans helyzetben, mint mondjuk 8-10 eve. Volt sok mas architektura, nem feltetlenul kellett volna pont az x86-ban gondolkoznia az AMD-nek."
Nagyon egyoldalúan nézed, mert az AMD (először másokkal együtt, később egyedül) tulajdonképpen segítettek az x86 elterjesztésében és dominánssá tételében. Nélkülük valószínűleg az Intel sem ott lenne, ahol van.
"Vagy ha megis, tervezzen sajatot, volt x86 licence, megtehette -- mint ahogy olyan kis cegek is megtettek akorul es utana, mint a NexGen es a Transmeta."
A NexGen első értékelhető chipje ugyanúgy a Pentium ellenfele volt és ugyanúgy saját uarc-ra épült, mint ahogy az AMD K5-öse. Kb. egy időben. A Transmeta kb. 5 évvel később lépett piacra termékkel.
"Es? A tobbiek (pl. AMD, Cyrix, NexGen, Transmeta, VIA, stb) miert nem csinaltak, es miert nem csinalnak mind a mai napig x86 forditot? Ha nem tetszik az, amit az Intel csinal, lehet fejleszteni sajatot."
Ez egy kissé cinikus kijelentés. Az Intel volt a domináns fél és nyilván ők csinálták a legjobb fordítót a saját procijaikhoz, így a fordítók terén is domináltak. Más gyártó fordítóját akkor használták volna szélesebb körben, ha legalább ugyanolyan jó Intelben, miközben más procira is jól fordít. Elég "érdekes" elvárás...
(#64) falco1: Íme egy jóval korábbi példa is: [link]
-
Fiery
veterán
Az a baj, hogy az AMD-t soha nem buntettek meg erdemben azert, amit csinalt. Se akkor, se most. En siman elvettem volna toluk az x86 licencet, es jatsszon mas az Intel elleneben. Akkoriban volt boven konkurencia, akinek volt x86 licence. Az AMD nelkul siman lehet, hogy a Cyrix vagy a NexGen lepett volna az AMD helyebe, es most nem AMD vs. Intel csata lenne, hanem Cyrix vs. NexGen vs. Intel.
Egyebkent a Btk-ban van jo nehany el nem evulo buncselekmeny, amiert 90 ev utan is lecsuknak. Just FYI.
-
Fiery
veterán
Ne haragudj, de egy buncselekmenyt azzal vedeni es az elkovetot azzal felmenteni, hogy a felhasznaloknak jott tett, eleg furcsa, leginkabb a Robin Hood-szeru romantikus torteneteket juttatja az eszembe. Az AMD non-profit cegkent kiosztotta minden uzleti ev vegen a profitjat az AMD processzorok vasarloi kozt? Az AMD bekerulesi aron adta a termekeit a felhasznaloknak, akiket a tenyeren hordozott az utobbi 30 evben? Ne vicceljunk mar... Loptak, csaltak, amivel elonyre tettek szert, es a vegen sokan jol eltek ebbol -- de nem a felhasznalok, hanem az AMD tulajdonosai es dolgozoi. Az Intelnek is volt sok mocskos huzasa, biztos hogy mind a mai napig megvannak, de az a teny onmagaban, hogy adott esetben a masik is csal es hazudik me'g nem mentesiti a tobbieket. Tudom, hogy vannak olyan orszagok, ahol nagy divat hangoztatni, hogy "Ha a masik is lophat, csalhat es hazudhat buntetlenul, akkor nekem is szabad", de ennek nem szabadna normalisnak lennie sehol a vilagon.
"A probléma MIND az Intel, MIND az nVidia módszereivel az, hogy megpróbálják ellehetetleniteni a konkurenciát."
Minden piaci folenyet orizni probalo ceg ugyanezt csinalja a piaci versenyen alapulo tarsadalmakban. Minden ceg fent akar maradni a csucson, amig csak lehet. Az AMD, Cyrix, VIA (stb) mind ugyanezt csinaltak volna az Intel helyeben. Nincsenek feher es fekete cegek, mind romlott, mind a penzt hajkurassza, az a dolguk, kulonben non-profit szervezetek lennenek.
-
Fiery
veterán
"A helyzet az, hogy semmi probléma nem lenne, ha ez a fajta működés végig publikus lett volna"
Egy szoftver gyartojat alapvetoen semmi sem kotelezi arra, hogy publikalja a szoftver hianyossagait vagy trukkjeit. Es az Intel soha nem szorgalmazta azt, hogy az ICC-t AMD vagy VIA procikhoz is hasznalja barki is -- vagy csak en nem emlekszem ilyesmire?
"Az Opel azonban nem említi, hogy a rendszer a speciális légzsákot csak akkor nyitja ki, ha Opelbe szerelik, ha Fordba akkor viszont NEM."
Az azert kicsit mas helyzet, hiszen ott 0 vagy 1 az eldontendo kerdes. Akkor lehetne ilyen analogiat felallitani, ha az Intel compiler altal forditott kod nem mukodne AMD vagy VIA processzoron helyesen, es az Intel erre nem hívná fel a figyelmedet. A kod abszolut helyesen mukodik, csak nem hasznal ki mindent trukkot, amit ki lehetne. De ahogy irtam fentebb is, ennyi erovel azt is fel lehetne hanytorgatni az Intelnek, hogy a konkurencia hasonlo fejlesztesei (pl. 3DNow!, XOP, FMA4) nem hasznalja ki az ICC.
"És itt a lényeg, ahol Fiery érvei elcsúsznak:"
Marmint szerinted
"Ugyanis a végén a felhasználó jár pórul (nem nyílik ki a légzsákja, lassabban fut a procija) nem pedig az, aki a fordítót használta"
A felhasznalo azert jar porul (bar ebben nem ertek feltetlenul egyet, de fogjuk ra), mert az AMD es a VIA nem kepes _sajat_ compilert kesziteni! Nem az Intel hibaja, hogy a tobbi gyarto lusta, es inkabb a konkurencia compilerere tamaszkodik. A felhasznalo meg vehet mas termeket is, semmi sem kotelezi egyik felhasznalot sem arra, hogy epp AMD, VIA (vagy Intel) termeket vasaroljon, es aztan azon ICC-vel forditott szoftvert hasznaljon. Van mas fordito, van mas CPU, lehet valogatni.
"És valahol nincs alternatívája az Inteles megoldásnak pl. Fortran fordítás esetén, ahol ugyanez a CPU dispatcher működik."
A _nagy tomegek_ szamara a Fortran nem hiszem, hogy relevans lenne. Vagy pl. egy atlagos PC-s konfiguracion hany olyan _performance-orientalt_ szoftver fut, amit Fortranban fejlesztettek?
"A helyzet egyébként az, hogy ez nem AMD fanboyok kifogása, van érvényes bírósági végzés, amely kötelezte az Intelt, nem másra, minthogy jeleznie kell a fordítói dokumentációjában ezt a fajta működést"
Ez ellen nincs is kifogasom, amig nem probalja meg egy birosag arra kotelezni a ceget, hogy direkt a konkurencianak is kedvezzen.
"Az Intel még ennek sem tett 100% -ig eleget. Felrakott egy képet a szöveggel az online dokumentációba, hogy ne legyen rá a weben találat"
Ugyes
Mondjuk en nem feltetlenul ertek ezzel a resszel egyet:
"“Artificial Performance Impairment” means an affirmative engineering or design action by Intel (but not a failure to act) that (i) degrades the performance or operation of a Specified AMD product, (ii) is not a consequence of an Intel Product Benefit and (iii) is made intentionally to degrade the performance or operation of a Specified AMD Product."
Ugyanis az SSE optimalizacio nem hasznalatatol az AMD termekeinek teljesitmenye nem csokken, csak nem nő mondjuk egy nem-SSE-képes AMD termekhez kepest. A direkt lelassitas inkabb azt jelentené az en olvasatomban, hogy a kodot direkt ugy generalja a compiler, hogy lassito ciklusokat iktat be AMD processzoron, vagy ugy allitja be a kod generalasnal az optimalizaciot, hogy a legkevesbe hatekony modszereket valasztja az x86 gepi kod keszitesnel, pl. MOV EAX,0-t hasznal XOR EAX,EAX helyett es hasonlok. Persze ez vekony hatarmezsgye, megertem a birosag/ugyesz erveleset is. Megjegyzem, szelsoseges esetben azt is megtehette volna az Intel, hogy a compilerben egy az egyben kikapcsolja az optimalizaciokat, es "naiv" uzemmodu gepi kodot fordit AMD meg VIA processzorokon, mint a legelso C forditok eseteben
Ahhoz kepest me'g egesz fair modon jart el -
-
Reggie0
félisten
Igazabol a konkurencia ellehetetlenitese nem is problema, ha ez tisztesseges piaci versenyben tortenik. Azaz x gyarto jobb minosegu termeket gyart (akar meg olcsobban) mint y gyarto. A problema, hogy itt nem ez tortenik.
Viszont azert nem kell mentegetni az AMD-t. A lopas az lopas es kesz. A robinhood nem egy eletszeru model.
-
SylverR
senior tag
Ajjajj.... Nagy a baj.
Egy 30 évvel ezelőtti esemény miatt szapulod az AMD-t, és véded ki az Intelt, miközben az Intel a mai napig műveli amit művel...
Amúgy rövidre fogom, nincs túl sok kedvem sokat belefeccelni ebbe a kommentbe:
A probléma MIND az Intel, MIND az nVidia módszereivel az, hogy megpróbálják ellehetetleniteni a konkurenciát. Nehogy véletlen jól fusson, nehogy véletlen jó legyen a felhasználónak. Nem. Csak az ő érdekeik számitanak, kizárólagosan!Az AMD kinek is ártott azzal, hogy koppintotta az Intel procijait? Az Intelnek? Kinek lett jobb? Neki, és a vásárlóknak? Hoppá...
-
falco1
tag
Kedves Fiery
Nagyra becsülöm munkásságodat, ezért megpróbálom a legnagyobb tisztelettel bemutatni azokat a hiányosságokat az argumentációdban, amelyek bizonyítják, hogy
“A forditot meg Te nem erted”.„Miert kellene egyaltalan mukodnie mas termekeken a fordito eredmenyenek… Az nem problema, hogy az Opel navigacio frissitese nem mukodik Ford autokon es viszont? Miert gond ez a CPU vilagban?”
Ez a helyzetnek egy nagyon nem találó leírása. Ugyanis azzal semmi probléma nem lenne, ha a fordító kimenete nem működne más termékén, és ezt tartalmazná a specifikáció. Az autós analógia így lenne helyes: az Opel navigációs rendszere a gyártó állítása és a specifikáció szerint is működik a Ford autókon, ellenben frissítés esetén szándékoltan elhangolja a gyújtást, amit viszont a gyártó (Opel) nem említ. Ez azt hiszem belátható, hogy az “autó világban” is gond lenne.
„ Az Intel keszitette, kesziti az Intel compilert, az o szellemi termeke, az o szoftvere, azt csinal vele, amit akar…
Az Intel tervezte az SSE-t is, mellesleg.
…Majd az Intel ugy dontott, hogy a sajat forditojaba, amit a sajat processzoraihoz tervezett, berak egy olyan korlatozast, amivel a konkurencia termeken a sajat SSE utasitaskeszlet hasznalatat nem engedelyezi. Minden joga meg volt hozza
…Miert kene reklamoznia? „A helyzet az, hogy semmi probléma nem lenne, ha ez a fajta működés végig publikus lett volna. Ez nem reklám, hanem specifikáció kérdése. Nem az a gond, hogy a reklám kitűzőn/golyóstollon nem szerepelt, hanem hogy semmilyen dokumentációban sem. Így ugyanis ez morálisan és jogilag is aggályos.
Hiába az Intel tervezte az SSE-t, azt bizony licenszelte más gyártóknak is. A helyzet autós vonalon így nézne ki: Az Opel tervez egy biztonsági rendszert speciális légzsákkal és a technológiát licenszeli más gyártóknak is. A megvalósítások, nevezetesen az Opelé és a Fordé egymással kompatibilsek. Az Opel azonban nem említi, hogy a rendszer a speciális légzsákot csak akkor nyitja ki, ha Opelbe szerelik, ha Fordba akkor viszont NEM. És ez Fiery szerint nem probléma. Tudom, hogy ez nem pont egy logikai szillogizmus, de nagyjából X,Y,Z behelyettesítéssel megkapod az Intel compiler sztorit.
Nem akarom azt sugalmazni, hogy meghalni= tapasztalni, hogy lassaban fut a proci, de logika szempontból ez irreleváns.És itt a lényeg, ahol Fiery érvei elcsúsznak:
„Eleve fura otlet lenne Intel compilert hasznalni AMD vagy VIA procihoz, aki ezzel probalkozott anno, es utana se nezett annak, hogy milyen kodot fordit a cucc, az meg is erdemelte, hogy azt kapja amit kapott”
Ugyanis a végén a felhasználó jár pórul (nem nyílik ki a légzsákja, lassabban fut a procija) nem pedig az, aki a fordítót használta.A helyzet egyébként az, hogy ez nem AMD fanboyok kifogása, van érvényes bírósági végzés, amely kötelezte az Intelt, nem másra, minthogy jeleznie kell a fordítói dokumentációjában ezt a fajta működést. Az Intel még ennek sem tett 100% -ig eleget. Felrakott egy képet a szöveggel az online dokumentációba, hogy ne legyen rá a weben találat
. -
Fiery
veterán
Egyik ceg se fizet semmit. Sajnos
En szemely szerint csak azt tartom furcsanak, amikor az egyik ceg csinal valami sulyosan illegalisat, hogy "palyan tudjon maradni", majd hosszas pereskedes vegen a sertett megis megturi a "palyan", es 20 evvel kesobb egyesek megis a sertettet tartjak a rosszfiunak. Teny, hogy ezek utan az Intel sem epp etikus vagy torvenyes modszerekkel probalta a konkurenciat letorni, de onmagaban az a teny, hogy az AMD eveken at masolt processzorokat arult sajatjakent, nem valtozik meg az ido mulasaval. Amikor meg vegul ra volt kenyszeritve a sajat CPU tervezesere, "furacsamod" meg tudta oldani a dolgot -- mint ahogy a Cyrix is, hogy csak egy plusz peldat mondjak.A vicc az, hogy ha ugyanez a tortenet mondjuk a Forma1-ben jatszodik le, azaz Forma1-ben indulasi licencet szerez egy uj vagy kevesbe uj csapat, befogadjak a tobbiek, majd lemasolja az egyik csapat autojat, es sajat emblemaval akar indulni, akkor ugy kivagjak a Forma1-bol, mint a huzat, es soha tobbet nem kaphat licencet nem csak ott, hanem mas autosportban sem. Az AMD meg kozben megtarthatta az x86 licencet, sot, tovabb gyarthatta az Am386 es Am486 processzokat, sot, tovabb is fejleszthette azokat (Am5x86), es mind a mai napig van x86 licence. Ahhoz kepest, amit anno muveltek, tok siman megusztak az egeszet, nagy szerencsejuk volt. Ne allitsuk be oket aldozatnak, nem kell. Nem arrol van szo, hogy egy szerencsetlen hajlektalan, akit kitaszitott a tarsadalom, bolti lopason kapnak, mert egy zsomlet es majkremet elemelt azert, hogy ne haljon ehen. Az AMD egy profit orientalt vallalat, ami abbol szerzett piaci elonyt, hogy ellopta mas IP-jet. Utana, ebbol kiindulva tizmiliard dollarokat kassziroztak. A fonokok es a beosztottak is ebbol kaptak a fizetesuket, senki se az eleteert kuzdve, ketsegbeeseseben "tevedt" az illegalitasba.
-
proci985
MODERÁTOR
-
-
Abu85
HÁZIGAZDA
Ebben a fordító kérdésben az FTC nem pont azért dorgálta meg az Intelt, mert nem fordítottak jó kódot az AMD procikra, hanem azért, mert nem dokumentálták, hogy bizonyos opciók az AMD termékeken másképp működnek. Ebből a szempontból az FTC kötelezte az Intelt, hogy hozzák a fejlesztők tudtára, hogy az AMD termékeket miben éri hátrány az ICC egyes beállításaival, illetve a régebben lefordított kódok esetében a panasszal élő fejlesztőknek minden supportpénzt vissza kellett adniuk.
Tehát nem azzal volt a baj, hogy nem volt optimalizált az AMD-re a kód, hanem azzal, hogy erről a fejlesztők nem tudtak, akik abban a hiszemben fordítottak ICC-vel, hogy ez jó lesz mindkét gyártó termékére. -
Fiery
veterán
"de senki sem várta el akkoriban és nem is fért volna bele az időbe, hogy az AMD (és a többiek) teljesen saját uarc-ot fejlesszenek a 0-ról."
Es? Akkor mar szabadon el lehet lopni masnak a CPU dizajnjat? Es hogyhogy a 486-os utan megis tudott az AMD teljesen sajat architekturat fejleszteni (K5), amikor abban az idoben mar sokkal komplexebbek voltak az x86 CPU-k, pl. volt integralt L1 cache es integralt FPU is? A 286-os, 386-os idokben ezerszer konnyebb lett volna nullarol x86 CPU-t tervezniuk.
"Van egy olyan fogalom, hogy fair play. Ez nem csak egy idealista elképzelés, hanem pl. a versenyhivatal is elég komolyan veszi..."
A fair play-be kapasbol nem fer bele a lopas. Amugy meg szabadversenyes kapitalizmus volt akkoriban az USA-ban, a verseny lenyege a verseny, es nem az, hogy ajnarozzuk egymast. Abban az idoben, amikor az AMD masolgatta az Intel CPU-it, az x86 kapasbol nem volt me'g olyan dominans helyzetben, mint mondjuk 8-10 eve. Volt sok mas architektura, nem feltetlenul kellett volna pont az x86-ban gondolkoznia az AMD-nek. Vagy ha megis, tervezzen sajatot, volt x86 licence, megtehette -- mint ahogy olyan kis cegek is megtettek akorul es utana, mint a NexGen es a Transmeta.
"Csak hogy kiüsse az AMD féle 3DNow!-t... (Derogált átvenniük.)"
Ez nem ujdonsag, a 3DNow! elott es utan sem vett at sok mindent az Intel a konkurenciatol, kiveve ha rakenyszerult. Megjegyzem, az SSE(1), es plane az SSE2, sokkal feljettebb utasitaskeszlet, mint a 3DNow!.
"Az viszont nem fordított olyan jó kódot (semmire). Így az Intel visszaélt a fordítója jóságával."
Es? A tobbiek (pl. AMD, Cyrix, NexGen, Transmeta, VIA, stb) miert nem csinaltak, es miert nem csinalnak mind a mai napig x86 forditot? Ha nem tetszik az, amit az Intel csinal, lehet fejleszteni sajatot. Ja, hogy az sok melo meg sok penz, egyszerubb hasznalni azt, ami van?
Alternativ megoldaskent az AMD-nek ossze lehetett volna fognia a Microsofttal, es a Visual C++ forditojat kicsit felturbozni, hogy jobb kodot forditson az AMD procikra. Ez megtortent vajon? Mert en nemigen hallottam ilyesmirol... -
MaUser
addikt
Teljesen jól látod. Amikor egy jobbnak mondható programozó mérnökórája 100€/$ (egy általad leírt több architektúrát ismerő meg többszöröse), egy uC meg max pár €, akkor csak célirányos projekteknél éri meg egyáltalán gondolni az optimizálásra. Nálunk pl. (hiába a milliós darabszám) ez úgy megy, hogy a procikat bekérik és a megért programoz letesztelik rajta, milyen gyorsak. A gyártók meg sokszor bámulnak, hogy a valóságban milyen gyenge is a procijuk és mennyire semennyit nem ér a sokmagos elrendezés az esetek 99%-ában. (Mert ugye nem mindenki képfeldolgozni akar...)
Az "optimizációról" meg annyit a gyakorlatban, akik a "lusta" programozókra fogják, hogy nézzük a cikkben említett mátrixszorzásos példát. A két india csóka elszüttyögött ezen egy hónapot, röpke 30-40.000$-ért. Elértek 64x-es gyorsulást. Ha van egy programod, ami csak mátrixot szoroz akkor ez kell neked. Ellenben ha van egy programod, ami 10x szoroz mátrixot egy indításkor, akkor minek ezzel vacakolni?
A coding standard-et amikor összeállítják a tapasztaltabb programozók az adott cégnél, akkor a tárolási struktúrákat megadják (akár a compiler adott fejezeteként, mert ez és a uC gyártó kiadott doksijai alapján csinálja az ember), ezzel pedig a cikkben említett scalar és vector részeket ki is lőttük. A programozó meg alapból tisztában van ezekkel 5-10 év munka után. Tehát a végén el lehet érni aránytalanul nagy befektetett munkával mátrixszorzásnál 2.4x-es gyorsulást. Hát remek.
Sokkal szimpatikusabb pl. az MS azon iránya, hogy az egyszálú programot dobja szét a fordító több szálra (már amennyire tudja).
-
-
dezz
nagyúr
Nem csak 8086 alapú IBM platformok jöttek ki, hanem későbbi procikkal is, ahol ugyanúgy elvárás volt az IBM részéről a x86 procik más gyártóknak való licencelése. Akkor kezdett fellépni az Intel a többiek ellen, amikor a PC kikerült az IBM ellenőrzése alól.
(#44) &rew: Akár ezzel is lehetne magyarázni, de: 1. erre semmi módon nem figyelmeztette sem az Intel, sem a fordító fordításkor a sw-fejlesztőt, 2. akkor is így tett, ha a fejlesztő külön kérte az illető utasításkészlet alkalmazását, 3. később, amikor erre fény derült, igen körülményessé tették a fordító által belinkelt procitípus-ellenőrzés kikerülését.
(#47) Fiery: Tudjuk a különbséget, de senki sem várta el akkoriban és nem is fért volna bele az időbe, hogy az AMD (és a többiek) teljesen saját uarc-ot fejlesszenek a 0-ról.
Van egy olyan fogalom, hogy fair play. Ez nem csak egy idealista elképzelés, hanem pl. a versenyhivatal is elég komolyan veszi...
Az Intel jópár dologban unfair, és nem csak a konkurenciával szemben, hanem közvetve a felhasználókkal szemben is.
"3) Az Intel tervezte az SSE-t is, mellesleg."
Csak hogy kiüsse az AMD féle 3DNow!-t... (Derogált átvenniük.)
"Ha valakinek nem tetszik az Intel vagy AMD szoftvere, nem kell hasznalni, van masik."
Az viszont nem fordított olyan jó kódot (semmire). Így az Intel visszaélt a fordítója jóságával.
"Ugyanigy, ha nem szimpatikus a vallalat, nem kell venni a termekeit."
Ez a fajta hozzáállás az arrogancia iskolapéldája.
-
Fiery
veterán
Az AMD az x86 ISA-t licencelte, nem a konkret CPU dizajnt. **rva nagy kulonbseg! Ha nem erted a kulonbseget, olvass utana kerlek, erdemes.
A forditot meg Te nem erted:
1) Az Intel keszitette, kesziti az Intel compilert, az o szellemi termeke, az o szoftvere, azt csinal vele, amit akar.
2) Az Intel ugy tervezte az Intel compilert, hogy az Intel processzorokon utos kodot forditson. Nem arra tervezte, nem azert szuletett, hogy mas hardveren jol mukodjon, jo kodot forditson.
3) Az Intel tervezte az SSE-t is, mellesleg.
4) Majd az Intel ugy dontott, hogy a sajat forditojaba, amit a sajat processzoraihoz tervezett, berak egy olyan korlatozast, amivel a konkurencia termeken a sajat SSE utasitaskeszlet hasznalatat nem engedelyezi. Minden joga meg volt hozza. 1 sor kod C-ben, nem tulsagosan extra munka, egy kodernek kb. 1 percnyi meloja.
Az meg, hogy ezt nem reklamozta, az is szive joga a cegnek. Miert kene reklamoznia? Vagy az AMD talan mindent vilagga kurtol, amit a sajat szoftvereiben implemental? Nem kotelezi ra oket az egvilagon semmi. Ha valakinek nem tetszik az Intel vagy AMD szoftvere, nem kell hasznalni, van masik. Ugyanigy, ha nem szimpatikus a vallalat, nem kell venni a termekeit, van alternativa.
-
pakriksz
őstag
Látom még mindig nem érted. Az Intel pont hogy foglalkozott az AMD procikkal a fordítójában, méghozzá úgy hogy úgy írta meg, hogy ha AMD procit érzékel, ne használjon a fordított program SSE utasításokat is, még akkor sem ha az AMD proci tudja.
Érted? EXTRA munkát ölt bele, hogy az AMD-n rosszabbul menjen, nem abba hogy optimalizálja, hanem az ellenkezőjébe. Ráadásul sunyi módon. Ha nem foglalkoztak volna semmit az amd procikkal, pont ugyanúgy ment volna a program mint intelen.
Az amd pedig licenszelte az x86-ot mivel az intel monopolhelyzetre való törése miatt át kellett adnia más cégeknek is a lehetőséget
Hivatalos volt minden, és legális. -
Strezi
őstag
Remek, ugyan ezt mondta az Intel 2005-ben is, amikor az első kétmagos desktop procikat kezdte nyomni. Én akkoriban voltam előadáson náluk
Szerintem amíg nem lesz egy mély paradigmaváltás a programozásban, addig a mulltiprocesszoros optimalizálás amolyan számkivetett, kevesek kiváltsága marad. Amíg a programozó lehetőséget kap arra, hogy tetszőleges mennyiségű "random" utasítást tudjon egymás után "biggyeszteni", addig a kódot nem lehet optimálisan futtatni több párhuzamos egységen. Vagyis ezt nem lehet garantálni.
Mondjuk, én nem panaszkodom, mert magam, és rajtam kívül még sokan ebből remekül megélünk
p.s. az általam írt fizkiai motor 7.3x sebességet tudott 8 magos Xeon-on. Azóta is köszi az Intelnek a procikért meg az első SSD-kért!!!
-
#25954560
törölt tag
anelkul h vedeni szeretnem az intelt, nem kizart, hogy az _is_ belejatszhatott ebbe a dontesbe, hogy egyszeruen nem ereztek ugy, hogy le kell tesztelniuk AMD procikkal. es mivel nem teszteltek le, nem engedelyeztek.
Fiery: koszi az eszrevetelt a magszamrol, javitva lesz. tizmagosokon dolgozom es automatikusan azt irtam
kromatika: koszi
-
dezz
nagyúr
Ja, még egy fontos dolog: nem kellene úgy beállítani, mintha az első x86-os procik a világ csodái lettek volna... (Az Intel alapvetően egy chipgyártó volt, aminek volt egy kisebb tervezőmérnök csoportja, akik különféle chipeket terveztek.) Pl. a Motorola 68k sorozata sokkal jobb volt! Nem is teljesen világos, hogy az IBM-nek miért nem erre esett a választása.
(#41) morgyi: Ahhoz nem kellene a Linux kernelt is átírni Javára?
-
dezz
nagyúr
"De ha egy CPU-gyarto sajat maganak, sajat termekeihez irja a forditot, akkor mi a feneert kellene foglalkoznia a konkurenciaval?"
Nagyon is foglalkozott vele: hiába tudta az AMD ugyanazokat a kiterjesztett utasításkészleteket, ezt a fordító nem csak hogy nem vette figyelembe, hanem megnehezítették ezek AMD-n való kihasználását.
"A 486-osig bezarolag siman lemasolta az Intel processzorait reverse engineering segitsegevel, es sajatjakent gyartotta + arulta. Sok helyen ezt nagyon finoman fogalmazzak meg, pedig csak sima pofatlan IP lenyulas volt, amit az AMD muvelt. Jobb helyeken ez buncselekmeny."
Tévedésben vagy! Ezt a részét nem olvastad el a cikknek:
"The year is 1981, and Intel (...) has just been chosen by IBM to supply the processor for the first personal computer. IBM wanted at least two CPU suppliers for its PC, and forced Intel to license its technology. And so it was that AMD became one of the first companies to sell an 8086 clone. AMD’s first processor went on sale in 1982. Because it was a licensed processor, the AMD 8086 (and 8088) was identical to Intel’s model."Tehát, megvolt a jogalapjuk a lemásoldásra. Azt meg senki sem várta, hogy 0 idő alatt csináljanak egy ugyanolyan procit a semmiből. Mellesleg nem egyezett meg a kettő az utolsó tranzisztorig, és az AMD több hibát is kijavított közben.
szerk.: látom, időközben szóba került a dolog.
-
Raucher
tag
..és úgy helyezzük be a procit egy sinbe ,mint egy videokarit...
Parancsolj, itt vannak a processzor kártyák.
Itt pedig a backplane, hogy legyen mibe dugni a processzor kártyákat, tudjanak egymással kommunikálni.A kínálatból azért látszik, nem ez a nagy áttörés ami megváltoztatná a mai gépeket belülről.
-
#38
Tejes Pite
aktív tag
M107
#3
-
vicze
félisten
Na igen utána jött rá az Intel há ez sikeres, és meg kéne tartani, persze mindez köszönhető volt a licencelésnek is, mármint a siker. Ugyanezen licence okán gyártotta tovább az AMD és ebből lett a per és végül "igazat kaptak", így vagy úgy.
Én azt mondom, hogy szerencse, mert 486-t után, hogy lett konkurencia, elég drasztikusan felgyorsult a fejlődés.
Nézd meg ARM-m csak licencet, ad és ultrabrutális fejlődést produkál, persze nem olyan magas a profit, de ha anno marad a licence modellnél az Intel ki tudja hol tartanánk... -
vicze
félisten
-
orbano
félisten
Azért messze nem csak lelkiismereti kérdés. Adott nekünk pl. egy kísérleti fázisban lévő metaheurisztikánk, amit C#-ban fejlesztünk a rugalmasság miatt. Ahhoz, hogy ezt tisztességesen tudjuk optimalizálni, kellene egy olyan ember, aki ismeri az összes szóba jöhető architektúrát (esetleg a közeljövőben érkezőket is), hogy el tudjuk dönteni melyik architektúrára lenne egyáltalán érdemes (nem determinisztikusan, sok kisebb, változatos felépítésű műveletet kell elvégezni kevés adaton, amiből az új adatok keletkeznek). Nyilván nem rentábilis vaktában próbálkozni. Szerintem elve nagyon kevés az ilyen szakember, nulláról kiképezni egy kollégát pedig iszonyatos idő/költség. Ráadásul ez a "tudományág" igencsak gyorsan fejlődik, ahogyan a hardverek, és a régi tudás gyorsan avul, szóval nem egyszerű, évente milliókat költeni egy-egy új hardverre való átállásra. Ez olyan szoftvereknél érheti meg, amik vagy elég kicsik és gyoprsan optimalizálhatók, vagy pedig olyan hardver kell alá, ami nagyon drága, és hosszú az életciklusa.
De szóljatok, ha rosszul látom! -
Fiery
veterán
Az, hogy a vegen, a birosagon ugyan, de megnyugtato modon zarult az egesz tortenet, es az AMD elindult a sajat processzor tervezes rogos utjan, me'g nem jelenti azt, hogy az elejen nem masoltak le illegalisan az Intel CPU-it hosszu eveken at. De lepjunk tul ezen, most mar mas idok vannak, most mar neha az Intel masol ezt-azt (pl. AMD64), de arra legalabb van keresztlicenc megallapodasuk, ugyhogy azzal nincs nagy gond, legfeljebb ciki
-
LordX
veterán
Persze, csak azért egyszerűbb lenne a helyzet, ha mikroarchitektúránként 1 db procira kéne gondolni, minthogy 3-4-re.
AMD oldalon viszont érdekes módon mindent tud a legkisebb, amit a legnagyobb, magok száma, cache méret csak a különbség. Igen, tudom, ez is optimizálási pont, de még mindig kevesebb, mintha azt is kellene figyelni, hogy most tud-e AVX-et vagy nem.
Turbo Boost mit számít optimizálási kérdésben?
-
LordX
veterán
Van egy határ, amin túl nem érdemes erőltetni a task alapú párhuzamosítást. Ha data parallel modellben meg érdemes, akkor berakok a Phi helyére egy Teslát, és laposra veretem vele. (Ugye így egyszerűbb szinkronizálni, de nehezebb a párhuzamosítást megoldani.)
Az egész egy tradeoff, egyik ebben jó, a másik abban. A probléma, hogy az Intel nem ad alternatívát, mert a Phi ugyanaz a modell, mint egy sima többutas szerver.
Bónusz kérdés: 2 db Xeon E5-2690 v2 vagy 1 db Xeon Phi 7120P? Árban egy kategória. 20 db Ivy Bridge 3 GHz-en, vagy 61 db Knight's Corner 1,2 GHz-en?
-
Fiery
veterán
"Nem, ilyen trükk nincs más fordítóban mert nem érdekük"
Persze hogy nem, mert a tobbi forditot nem egy x86 CPU gyarto irja, hanem mondjuk a Linux kozosseg vagy a Microsoft (Visual C++), azaz kvazi fuggetlen identitasok. De ha egy CPU-gyarto sajat maganak, sajat termekeihez irja a forditot, akkor mi a feneert kellene foglalkoznia a konkurenciaval? Miert kellene egyaltalan mukodnie mas termekeken a fordito eredmenyenek? De ha megis mukodik, csak nem 100%-ig optimalizal, az a gyarto hibaja?
Vedi a sajat termekeit, a sajat piacat, ez teljesen normalis. Az nem problema, hogy az Opel navigacio frissitese nem mukodik Ford autokon es viszont? Miert gond ez a CPU vilagban?Az AMD-nek meg nezz utana kicsit alaposabban. A 486-osig bezarolag siman lemasolta az Intel processzorait reverse engineering segitsegevel, es sajatjakent gyartotta + arulta. Sok helyen ezt nagyon finoman fogalmazzak meg, pedig csak sima pofatlan IP lenyulas volt, amit az AMD muvelt. Jobb helyeken ez buncselekmeny. Onnan indultak, azota jo utra tertek, de ettol me'g a multjukat nem lehet megvaltoztatni.
Imitation To Innovation: AMD's Best CPUs
"The 486 was the last clone of an Intel processor."
-
pakriksz
őstag
Nem szokta. Nagyvállalatok használták az intel C fordítóját, és sok év után derült ki csak a trükk. Nem, ilyen trükk nincs más fordítóban mert nem érdekük, csak az intelnek van ilyen érdeke. Olyan sok választás azért nem volt, a GCC csak az utóbbi pár évben vált igazán jóvá.
"Egyebkent ne allitsuk mar be egy gonosz brutalis allatnak az Intelt, es egy josagos, szegeny kis szerencsetlen szenvedonek az AMD-t."
Miért ne? Gyakorlatilag az intel történelme abból áll hogy mutyi, lefizetés, FUD, trükközés, stb, mint az ex "élettársáé" a microsoft történelme. Mivel jutott az amd oda ahol van? Mit csinált az amd? Hányszor kapták a fentieken (ez elég vicces mert nincs is pénzük lefizetni).
-
Fiery
veterán
Bocs, de egy sor a forditoban egy ilyen "trukk". Nem nagy melo
Es nem kotelezo hasznalni az Intel compileret. Eleve fura otlet lenne Intel compilert hasznalni AMD vagy VIA procihoz, aki ezzel probalkozott anno, es utana se nezett annak, hogy milyen kodot fordit a cucc, az meg is erdemelte, hogy azt kapja amit kapott. No offense, de aki mar SSE-ben meg AVX-ben gondolkozik, az meg szokta nezni, hogy egy C fordito mit muvel, egyaltalan produkal-e vektorizalt kimenetet. Aki meg igazan komolyan gondolja a vektorizaciot, az ugyis inkabb assemblyben kodolja le a teljesitmeny-erzekeny reszeket, nem bizza egyik C forditora se a vektorizaciot.Egyebkent ne allitsuk mar be egy gonosz brutalis allatnak az Intelt, es egy josagos, szegeny kis szerencsetlen szenvedonek az AMD-t. Elobb erdemes utananezni, honnan indult az AMD es mivel jutott el oda, ahova eljutott ma. Tanulsagos dolgok vannak a tortenelmukben -- mint ahogy az Inteleben is.
-
pakriksz
őstag
Az intel saját költségen direkt olyan fordítót készített ami DIREKT arra ment hogy ne működjön jól a konkurencia termékein. Tehát külön azzal foglalkoztak, töltöttek el vele extra időt, hogy amd-n rosszabb legyen, és fordítottak rá pénzt. Ha nem csináltak volna semmit ugyanúgy ment volna. Ráadásul mindezt sunyiban, amíg le nem buktak.
Röviden ők nem nem optimalizáltak, hanem ellen-optimalizáltak. -
Fiery
veterán
Ha az Intel sajat forditojarol van szo, akkor megis mi erdeke lenne az Intelnek olyan forditot gyartani a sajat koltsegen, ami a konkurencia termekehez is jol mukodik? Jo hogy ne mar azt varjuk el az Inteltol, hogy XOP-re meg FMA4-re is optimalizalja a forditojat, hogy az AMD-nek meg se kelljen mozditani a kisujjat...
Van egyebkent masik C fordito Windowsra, lehet azt is hasznalni, ha az Intel-fele nem felel meg.
-
Fiery
veterán
"És ebben a legfőbb genya maga az Intel, mert amikor az i7-el azonos magra épülő Celeronban/Pentiumban letiltják az új utasításkészletek felét, akkor ha azt akarod, hogy mindenhol fusson a programod akkor búcsút mondhatsz a AES-NI és társai utasításoknak"
Nem mintha AES-NI minden x86 processzornak resze lenne, kiveve a Celeronokat es a Pentiumokat. Ha azt akarod, hogy a szoftvered mindenhol fusson, akkor bele kell kalkulalni az AMD es VIA CPU-kat is. Azokban meg vagy van AES-NI tamogatas (pl. FM2-es AMD procik), vagy nincs (pl. FM1-es es regebbi AMD procik, VIA procik). Azert ne allitsuk mar be az Intelt a fo genyanak, mert piaci szegmentalaskent nem adnak minden "josagot" oda a legolcsobb procijukhoz is... Ennyi erovel adjak oda a Celeronoknak a 4 magot meg a HyperThreadinget meg a Turbo Boost-ot is, azok is hasznosak lennenek ott
Megjegyzem, egy Celeronnak meg Pentiumnak pont nem az AES-NI hianyzik leginkabb ahhoz, hogy gyors(abb) legyen... -
pakriksz
őstag
hát igen az optimalizációban az intel a legnagyobb gyenya. Náluk az optimalizáció csak akkor jó ha éppen a céljaikat szolgálja. Ha nem akkor ellenség.
Lásd az Intel C fordítót, ami pár éve még amíg észre nem vették, AMD procit észlelve kiiktatta az SSE utasításokat használó kódot. Vagy ahogy jelenleg így meg úgy próbálja a GPU-k általános felhasználását hátráltatni mert az ő gpu-ik gyengék. -
#18
LordX
veterán
Blindmouse
#7
LordX
veterán
válasz
Blindmouse
#7
üzenetére
Úgy optimizálni, hogy kicscsillió különböző utasításkészletet támogatnak a procik, nem egyszerű.. És ebben a legfőbb genya maga az Intel, mert amikor az i7-el azonos magra épülő Celeronban/Pentiumban letiltják az új utasításkészletek felét, akkor ha azt akarod, hogy mindenhol fusson a programod akkor búcsút mondhatsz a AES-NI és társai utasításoknak... (És akkor még azt a kérdést is fel lehet tenni, hogy kinek van Xeon Phi-je?)
-
Cifu
félisten
Nehany 8086-os intel procival egy egesz ursiklot vezereltek, most meg 2 mag keves egy SMS gyors megnyitasahoz.
Az a néhány 8086-os proci viszont direkt rá írt és fordított programot futtatott, ami cirka egy megabyte-ot nyomott, és szigorúan meg volt szabva milyen feladatot lásson el. Ehhez képest a telefonon van egy kernel, rajta egy libraries, azon egy application manager, és ezen fut maga az app. Azért így működik, mert kismillió féle appot akarhatsz te a telefonon futtatni, más-más feladatokra. Szóval kissé unfair az összevetés...
(Csak érdekességként: mikor az 1990-es években az űrsiklók pilótafülkéjét modernizáltá - Glass Cockpit - és több LCD kijelző is megjelent, akkor már 80386-osokat használtak)
-
#15
jerry311
nagyúr
dragon1993
#14
jerry311
nagyúr
válasz
dragon1993
#14
üzenetére
Ne szamitsak frissitesre?
SGS 2, Android 4.2 is van ra gyarilag, ha kellene, szerintem ez eleg szep teljesitmeny nehany masik gyartohoz kepest. Egyebkent mas fut rajta, mert gyorsabb, meg nem TouchWiz de igy se tokeletes. Mindegy is, ennek nem a telefonrol kellene szolni, az csak egy pelda volt, hogy mennyivel nagyobb teljesitmenyre kepesek a mai gepek, megis sokkal kevesbe gyorsultak a programozoi ellustulas miatt.
Nehany 8086-os intel procival egy egesz ursiklot vezereltek, most meg 2 mag keves egy SMS gyors megnyitasahoz. Valami nem jo iranyba indult itt el valamikor...
Remelem ertheto mit akarok itten mondani.
Ilyen szmepontbol nagyon helyesnek tartom, hogy az intel probalja optimalizalasra tanitani 'gyermekeit'. -
#14
dragon1993
addikt
jerry311
#10
dragon1993
addikt
Az android megint egy másik kérdés.
Az androidnak nem kell 4 mag és 2gb ram.
A gagyi 3 perc alatt összedobott (sőt szerintem direkt) teljesítménypazarló felület amit rátolnak azzal van a gond.A gyártónak nem érdeke optimalizálni , mert az időbe tellene és drága lenne illetve az átlagvásárlót ezzel nem megfogni.
Ők így gondolkoznak : "Ez is androidos meg a másik is az
"
Majd megveszi hazaviszi laggol levonja a következtetést ,hogy sz@r az android vagy egy fokkal jobb ha a gyártót szidja.A frissítésre meg nagyon számíts mert már megvetted, rád sózták, pénzt belőled nem látnak vegyél újat.
Megoldás: Vegyél nexust ami a magyar bérekhez hasonlítva még mindig nem olcsó
Most mondhatjátok a CM-et , de ők sem tudnak csodát tenni gyártói támogatás nélkül.
(#13) SylverR
Rátapintottál otthon nem fogsz crysis-t írni. De még CS:S-t sem.
-
#13
SylverR
senior tag
Ivy.4.Ever
#12
SylverR
senior tag
válasz
Ivy.4.Ever
#12
üzenetére
Ha ezen akadsz fent, nem érted a kommentje lényegét.
A 97-es MDK nagyobb látványorgazmust adott annak idején, mint bármilyen játék manapság.
És nem azért, mert annyit fejlődött a játékipar, hogy már nem lehet olyan ugrást elérni. Ellehetne. Csak a programozók vagy lusták, vagy nem kapnak elég pénzt. Aki meg szivből csinálná...hát lássuk be. Olyan manapság már nincs. Vagy egy Crysis szintű játék 30 évébe telne. Persze nem csak a játékok vannak. Vannak milliomegy alkalmazások, amikben lehetne jobban teljesiteni. De sajna a pénz az úr.[Trolling mode on]
Mellesleg, mikor megláttam a "párhuzamositás és optimalizálás" szóösszetételt az Intel neve mellett, hangosan felröhögtem.
[Trolling mode off]De a cikk az jó.
-
Alchemist
addikt
Amikor valamit triviális párhuzamosítani, arra ott van a zillió darab GPU unit.
De ha nehezen jósolhatók meg az egyes szálak várható állapotai, ráadásul ezeket össze kell hangolni, a unit-ok/magok számának növelésével az overhead lassan felfalja a teljesítmény növekedést... -
#10
jerry311
nagyúr
dragon1993
#9
jerry311
nagyúr
válasz
dragon1993
#9
üzenetére
Az egy dolog, hogy draga volt, de attol fuggetlenul sokszor elerhetetlen volt a nagyobb teljesitmeny. nem maradt mas, mit az optimalizalas.
Ma meg mar egy telefonban is 4 magos processzor van 2 GB RAM-mal es lassabban nyit meg egy SMS-t, mint a 10 eves Nokia, pedig az SMS ugyanaz a 160 ekezetmentes karakter...
Elkenyelmesedtek a programozok. Nem kicsit. -
jerry311
nagyúr
Volt mar ilyen... Slot A / Slot 1 ugy AMD vagy Intel.
Blindmouse
Ez gyakorlatilag barmelyik x86 hardverre es szoftverre igaz. Eleg soka tart, ming a programozok elkezdik rendesen kihasznalni az osszes hardverbeli lehetoseget. Regen jobban ment nekik, igaz akkor sokkal okosabban kellett banni az eroforrasokkal... -
#7
Blindmouse
senior tag
Blindmouse
senior tag
Tehát az intelnél beválalják, hogy a szoftverek 8-10 évvel vannak elmaradva a hardverektől.
-
#25954560
törölt tag
nem pontosan ezt javasolja.
azt fejtegette, hogy van egy hatar, amin tul nem erdemes vagy egyalatalan ertelmes eroltetni a parhuzamositast.
ha van egy rendszered phi-vel, akkor attol meg, hogy konkretan az egyik programod nem kajalja fel az osszes magot, nem jelenti azt h a procit rosszul hasznalod ki. lehet pl tobb kliensed, akik mondjuk egyenkent kapnak 6 magot, mert ugy futnak a leghatekonyabban. akkor mondjuk fellosz ebbol nyolcat core pinninggel, a fennmarado 12 magon pedig futhat pl egy proxy akarhany magon, aki a klienseket latja el adattal a foglaltsaguk mertekeben, a fennmarado akarhany magon pedig futnak a background taskok.tehat a phi-t kihasznaltad a leheto legjobban, de a programaid egyenkent csak x szalat hasznaltak.
sajnalom, ha felreertheto volt.
-
M107
addikt
Magyarán most következik ami még nem volt, kihasználják az adott CPU és GPU erőt, s lám 100000% teljesítmény növekedést érnek el.
Utána, folytatják a csíkszél csökkentést, de már akkor minden egyes NM -kor a végtelenségig optimalizálják a dolgokat.
Eredmény még egy 6 magos Intel s AMD procit eladása többször csak az optimalizáció szintje nem mindegy.
S akkor még nem beszéltük az APU-k ról. -
" Ennek legkézenfekvőbb megoldása az órajel növelése volt, azonban egy bizonyos határnál már nem éri meg vagy egyszerűen nem megoldható a további emelés (bár az Intel kutatólaboratóriumában volt 10 GHz-en üzemelő processzor is, mint az kiderült egy másik előadáson). "
OMG!
Én is én is.
OFF világbajnokság! ![;]](http://cdn.rios.hu/dl/s/v1.gif)
jartunk igy mar mi is. es persze tele van 'workaround' meg 'temporary solution' kommentekkel. a minosegi munka halala.
Nem fognak, mert most mar a HSA-val foglalkoznak inkabb.
808286 = 134 ezer tranzisztor, K5 = 4,3 millio tranzisztor. Aki az utobbit ki tudta fejleszteni sajat kutfobol (AMD), az 100%, hogy az elozot nem tudta volna 
Új hozzászólás Aktív témák
- Erős törpe: ASUS NUC 15 Pro+
- Forza sorozat (Horizon/Motorsport)
- Apple iPhone SE (2020) - életképes alternatíva
- ASUS routerek
- Videós, mozgóképes topik
- LED világítás a lakásban
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Real Racing 3 - Freemium csoda
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- BMW topik
- További aktív témák...
- KÜLÖNLEGES RITKASÁG!!! VADIÚJ Surface Pro 12 12" Snapdragon X Plus 16GB 512GB LEVENDULA 686g
- GYÖNYÖRŰ iPhone XS Max 64GB Gold -1 ÉV GARANCIA - Kártyafüggetlen, MS3298
- Bowers/Wilkins PX8 fejhallgatók (dupla Bluetooth eszköz csatlakoztatása!)
- Gamer egerek és billentyűzetek kitűnő árakon! Most extra 10% kedvezmény!
- Készpénzes / Utalásos Videokártya és Hardver felvásárlás! Személyesen vagy Postával!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest