Új hozzászólás Aktív témák

• #5 P.H. senior tag fLeSs #1

  Új Válasz 2008-01-17 19:01:19 #5

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  P.H.

  senior tag

  válasz fLeSs #1 üzenetére

  Az x86-nak több változata is van?

  Elsőre az ugrott be, hogy lehet, nem lesz bennük Microcode ROM, esetleg még read-modify-write utasítások sem, és csak a közvetlenül 1 (fused) micro-opra fordítható utasítások maradnak. Nem lenne nagy érvágás.

  Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

• #17 P.H. senior tag #95904256 #15

  Új Válasz 2008-01-17 20:10:17 #17

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  P.H.

  senior tag

  válasz #95904256 #15 üzenetére

  Kifejezetten általános célokra szánják, kifejezetten x86 utasításkészletre alapozva. ("It will be easily programmable using many existing software tools, and designed to scale to trillions of floating point operations per second (Teraflops) of performance. The Larrabee architecture will include enhancements to accelerate applications such as scientific computing, recognition, mining, synthesis, visualization, financial analytics and health applications." [link], bár elég régi, ez újabb.) A jelenlegi x86-fordítókat minimális módosítással kompatibilissé lehet tenni; lehet, hogy 2009-ben pl. olyan Visual C fordítót kaphatsz, ami tud erre is fordítani.

  Ez a gondolatmenet így, tömören leírva kifejezetten szimpatikus:

  The Larrabee architecture could be characterized as the anti-GPU entry. The overall approach is an attempt to evolve the CPU into a terascale data parallel engine. According to Intel, Larrabee will be a manycore (i.e., more than 8 cores) device and will be based on a subset of the IA instruction set with some extra GPU-like instructions thrown in. Intel has not elaborated on how it intends to do this, but one could imagine super-sized SSE units with just enough x86 CPU silicon to enable general-purpose flow control and data access. The first product release will probably come in 2009, but Intel says it may have something to demo as early as next year.

  The idea behind Larrabee is to bring both traditional graphics processing and data parallel computing under the IA umbrella. I'm not going to talk about the traditional graphics side of the story here (I'll let the game weenies argue about the advantages of ray-tracing over rasterization.) What's interesting about Larrabee and its GPU brethren is the extent to which a graphics engine can become a general-purpose computing engine without compromising its performance.

  The combination of a data parallel engine with more of the general-purpose flexibility of a traditional CPU could offer a powerful model for scientific computing applications, which usually consist of an irregular mix of matrix math and other logic. One of the drawbacks of traditional GPUs is that they depend upon an accompanying CPU for virtually all of the non-vector logic. That's fine if the application divides neatly between a vector computing kernel and the rest of the application logic in such a way as to keep both types of processing engines busy. But if it doesn't, the software developer has to find a way to tease out enough parallelism for the GPU to make sending the vector data on a round trip from the CPU worthwhile. This will only get worse in the future, since chip-to-chip bus performance is not expected to keep pace with either CPU or GPU performance.

  [ Szerkesztve ]

  Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

• #33 P.H. senior tag kisfurko #29

  Új Válasz 2008-01-18 23:39:56 #33

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  P.H.

  senior tag

  válasz kisfurko #29 üzenetére

  Az Intel megint a 'végletekből végletekbe' játékrendet mutatja be, mint pl. az órajel utáni IPC-növelés (ami manapság megint átcsapott órajel-versenybe - tick-tack? -; de ugyanez volt kicsiben a 486-Pentium-PPro idején is). SZVSZ most nem akarja azt, ami az Itaniummal történt, hogy megfelelő fordító (vagy API, amibe a programozók nagyrészt nem látnak - közvetlenül - bele) meglétén múljon egy nagy számítási kapacitású termékének általános sikere.

  "hiába az x86-os kód (ami inkább teher)"
  "Senki nem gondolta volna, hogy a 8086 valaha is sikeres lesz, sőt az egész x86 vonal, és lám, mi van. Ezeket a kérdéseket nem szakemberek döntik el, hanem idióta üzletemberek."

  Miért van ekkora ellenérzésed az x86-felépítések iránt? Azt hiszem, mindketten ismerjük a korlátait, de még sincs általánosan más architektúrákra assembly topik a fórumokon. És ha lenne is, melyeket lehetne kézzel annyira idő-/költség-/erőforrás-hatékonyan programozni, mint egy x86-ot (~ library-k)? SZVSZ az Intel most erre alapoz.

  Általánosan:

  Itt az eredeti cikk, aminek egy részét idéztem #17-ben.

  "Like Intel, AMD has hinted at adding GPU-type instructions to the x86 ISA to allow software to work seamlessly with the graphics engines via a standard compiler/runtime. If AMD and Intel were on speaking terms, they could forge a common GPU ISA, which would be much appreciated by the GPGPU ecosystem. It could also serve to blunt NVIDIA's lead, and probably force the company to adopt what would be an industry-standard GPU interface. In the short term, standards are unlikely. Everyone involved has their own vision of how the GPU should evolve into its new role."

  Rövid távon tényleg nem látszik hasonlatosnak az Intel és az AMD megoldása, de miért ne lenne 'beszélő viszonyban' egymással a két cég?

  [ Szerkesztve ]

  Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

• #37 P.H. senior tag fLeSs #35

  Új Válasz 2008-01-19 14:17:12 #37

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  P.H.

  senior tag

  válasz fLeSs #35 üzenetére

  Az érdekes lesz, hogy az Intel hogy fog hozzáállni az SSE5-höz. Talán ez lehet még olyan ütőkártya az AMD kezében, mint az x64 volt, és ez már teljesen készen áll. ("These instructions use opcodes 0F 24 00–FFh and 0F 25 00–FFh.")
  Vagy átveszi, vagy teljesen új, önálló útra vezeti az x86-vonalat: a Larrabee és utódai elég erős indokok lehet ahhoz, hogy valamikor a jövőben végleg lekoptassák az x86 ISA feleslegesen magával cipelt részeit, CPU szinten is, (pl. a rep movs típusú utasításoknál megjelenése óta sokkal gyorsabb az SSE-k non-temporal megközelítése, csak ugye a megszokás...) és értelmesen egészítsék ki.

  Még mindig: ""Processor" shall mean any Integrated Circuit or combination of Integrated Circuits capable of processing digital data, such as a microprocessor or coprocessor (including, without limitation, a math coprocessor, graphics coprocessor, or digital signal processor) that is capable of executing a substantial portion of the instruction set of an AMD Processor or an Intel Processor."
  Az Intel vagy marad a kétoperandusú műveleteknél és csak a futtatási SIMD-egységeket szélesíti ki, vagy átveszi az SSE5-öt (egy részét), vagy ugyan alkalmazni fog többparaméteres utasításokat, csak teljesen más gépi kódokkal (na ez szép lesz).

  "És az ilyen topikokat egyébként sem a PH-n kell keresgélni."

  Nem is itt hiányoltam, úgy általában. Azt gondolom, az x86 assembly valahol az 'általános műveltség' része. De az is jó (de flame-keltő) kérdés lenne, hogy miért pont ez terjedt el.

  dezz: ez szerintem csak szimpátia (részlet)kérdése, vagy azé, hogy ki min kezdett, mióta a hardware tényleg tudja tartani a lépést a kódja komplexitásának növekedésével. Nekem x86-on könnyebb programozni, kicsi registerkészlettel, viszont jó adag utasításonkénti sideeffect-tel. (Amúgy szerintem egy 'teljesen igazságos világ' az IA64-féle megközelítést használná már - a programozó programíráskori 'miért'-jei is kerüljenek bele közvetlenül a gépi kódba, ne csak a 'hogyan'-jai, mindez terjengős végeredmény nélkül.)

  kisfurko #36: ősszel szabadidőmben elkezdtem átolvasni az összes eddig PH!-n megjelent processzor-hírt és a topikjaikat, ismerem ezt is, ezért kérdeztem. A 8086 oktatására vonatkozó résszel egyetértek, én 32 bites valós móddal kezdtem, aztán gyorsan vissza kellett térnem egy időre 16 bitre - rémálom -, ezt azt hiszem, írtam is egyszer az assembly-topikban.
  Lehet, hogy kicsavart a gondolkodásom, de úgy érdemes elkezdeni egyre közelebb kerülni egy hardware-hez, ha tudod, mire képes, és egy idő után ki tudod jelenteni, mire lenne szükség a nagyobb hatékonysághoz (ne akarj profi felhasználó maradni, légy kezdő alkotó, egy szinttel feljebb, mindíg). Ekkor látszik, hogy felfogtad a lényegét - ha mégsem, profi felhasználónak is jó lenni.
  Nem nagy belelátással, de azért ismerem a kezdő x86 assembly-programozók hozzáállását. Azt a hét regisztert sem merik kihasználni, ami rendelkezésre áll, EAX-EDX az isten, a többi mintha tabu lenne, nagyobb lehetőségek között elvesznének (nem sokban különböznek az x86 compiler-ektől ). Őszintén szólva én is elvesznék, ha egy regisztert a kódban képernyőnként egyszer látnék, az esetek többségében maradnék csak néhány használatánál. De ezzel meg megint visszakerülünk oda, hogy ez szimpátia/előélet kérdése.

  [ Szerkesztve ]

  Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

• #42 P.H. senior tag kisfurko #39

  Új Válasz 2008-01-19 20:05:16 #42

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  P.H.

  senior tag

  válasz kisfurko #39 üzenetére

  Miről beszélsz? A szavakat nagyjából értem, de a mondandót nem.

  Csak hogy ne az legyen a válasz, hogy olvassak utána, lámaként, lépésenként kérdezek:

  - Egyébként ez a regiszterekben való elveszés is csak azért van, mert az x86-os assemblerek bénák (voltak?) Ha assembly-ben programozok, mibe van beleszólása a fordítónak?
  - "Simán aliast adsz egy regiszternek." x86-os assembly-ben hogyan?
  - "Vagy ha C-be ágyazott assembly, akkor lokális változók, s a fordító lefoglalja neked a regisztereket." Nem C-ben programozok, hanem assembly-ben.
  - De még az SSE se megváltás, mert nincs annyi regisztered, hogy egy nyamvadt 4*4-es mátrix beférjen, ergó nincs gyors transzponálás. Pedig belefér egy 4*4-es mátrix, x64-en kívül is (4*32bit*8 vagy 2*64*8). A memória kihagyásával történő transzponálás miben/hogyan működne optimálisan? Komolyan kérdem, register-ek közti átrendezést, több (4?) írt regiszterrel mi támogat?
  - Nincs beépített shuffle, meg maszkolás stb. Mi az, hogy beépített?
  - Megnézhetné mondjuk intel a PSP vektoregységét, hogyan kéne minimum kinéznie egy vektoregységnek. De az AltiVecről is vehetett volna példát. És ugyanez igaz volt az MMX-nél, de még a 8087-es koprocesszornál is. Bővebben?

  [ Szerkesztve ]

  Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

Új hozzászólás Aktív témák