Intel: Órajel növelés a teljesítmény rovására is

Oldal 1 / 3Következő →

Jelentkezz be a hozzászóláshoz.

mir
#149
"Nemtom.Szerintem a lieáris algebra nem egy vészes terület.Szeintem csak nem mélyedtél bele igazán,vagy én nem tudom rendesen.:-)"
ebben egyetértünk: valóban nem nehéz, csak nekem megmaradt a jó középiskoláés szokásom, hogy úgy kell levizsgázni a lehetõ legjobban, hogy közbe semmit se tudok. tehát pótolni kell. mail megy.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#146
ha dobsz eg mailcímet küldöm a kvaterniós anyagot.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#145
"Na,most végigolvasva a mirrel folytatott beszélgetésemet,jópár matematikai szakszót írtam rosszul,illetve vétettem néhány hibát.Sorry."
ez sajnos van nekem is bõven, nincs még elég nagy gyakorlatom e téren, és ha nem olvasom át 2* amit leírok(mint ahogy nem szoktam) akkor hemzseg a hibáktól.

Nos a kvaterniókról van vagy 3/4 oldal de az egy készülõ jegyzet 40 oldalas részének a legvége, az elõtte lévõ dolgok nélkül nehezen érthetõ. azaz inkább értelmetlennek tûnik minden, amit abban leírnak. a többi dolgot felsõbbévesektõl hallottam, még nem tartok ott. angolul a neten biztos van sokmminden, de még sajnos nem vagyok olyan szinten, hogy ez beszédtémán túl is érdekelhessen.

"Hú,ha valamelyik mûvelet sorrendje nem felcserélhetõ,már ilyen kúl szavat lehet használni?kúl"
szakmai ártalom, de ha minden szakszó helyett a magyar(a tényleg magyar, nem magyarított) szavakat használnánk, akkor a könyveink legalább kétszer, de inkûább háromszor lennének hosszabbak, és jóval áttekinthetetlenebbek(mert egy magyarított szót gyakran csak mondjuk egy olyan 10-15 szavas mondattal, vagy a definícióval lehet helyettesíteni)
sorry

"Egyébként gépészmérnök vagyok,és se c++ programozást,se 3d grafikát nem tanultam.Ez csak a hobbim.:-)
Ha hétköznap melósokkal kell vitatkoznod,meg idióta beszállítokkal,akkor ez egészen jó kis kikapcsolódás.:-)"
a 3D grafikához sok linalg kell, amit én nem tudok, most vizsgáztam belõle egy hármast, azt sürgõsen javítanom kell. ha már átlátod ezeket a dolgokat ösztönösen, akkor az egy nagyon komoly szint. a linalg tipikusan az a tárgy szerintem, amit könyû bemagolni, de valóban megérteni nehéz, és emellett fontos is.

"Most ez a 16 dimenzió mint megnevezés igazábol a mátrixot mint szám éretlmezi.Hopsz,ez is ferdetestet alkot.:-)kúl
Az pedig,hogy a "mátrixot 4 dimes vektortérnek tekintem" írásom pedig eléggé nagy marhaság,hiszen a mátrix az általam leítr öszefüggésben nem alkothat vektorteret."
nem a 16 dimenzió az a vektortérre vonatkozik. a vektortér elemei vektorok, a számtest elemei számok. ha nagyon bele akarjuk erõszakolni a dolgot, akkor sem mondhatjuk, hogy a vektortér test, mert a nullvektornak nincs skalárral-való-szorzásra nézve multiplikatív inverze(double sorry)

van itten egy kis anyag, egy haverom készítette: algebrai struktúrák
azt hiszem, hogy ebben még vannak hibák, valahová összeírtuk, mi mindent kellene javítani, de még szerintem nem csinálta meg, meg ha megcsinálta volna sem lenne meg nekem az új változat.
ha valami nagyon illogikusan néz ki, akkor az valóban hibás lehet.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#143
"Many game programmers have already discovered the wonderful world of quaternions and have started to use them extensively. Several third-person games, including both TOMB RAIDER titles, use quaternion rotations to animate all of their camera movements. Every third-person game has a virtual camera placed at some distance behind or to the side of the player's character. Because this camera goes through different motions (that is, through arcs of a different lengths) than the character, camera motion can appear unnatural and too "jerky" for the player to follow the action. This is one area where quaternions come to rescue. "
nos, a TOMB RAIDER kamerakezelése negatív példaként állhatna mnden játékfejlesztõ elõtt:D
de ettõl függetlenül ez érdekes dolog, ezzel még nem találkoztam.

"Ezzel még nem találkoztam.A mátrixokat én a rangjának megfelelõ dimenziójú vektortérnek tekintem.Mi a franctól lehetne egy 4*4-es mátrixra azt mondani,hogy 16 dim.-es vektorterû?"
az a in T^{n times m} mátrix T számtest felett n*m dimenziós vektortér. csakis n*m. lehet más számtest felett más dimenziós, de T számtest felett csak n*m-es. Tehát az n times m alakú mátrixok t szt. felett n*m dimenziós vektorteret alkotnak, mert teljesülnek az axiómák, amiket most nem bizonyítanék.

"Mi a franc az az algebrai ferdetest?"
ugya a kvaterniókat szemléletesen számpároknak tekinthetük, két komplex szám által alkotott számpárnak.
a kvaterniók azért ferdetest, és nem test, mert a szorzásuk nem kommutatív. egyébként az összes tulajdonságuk megegyezik bármely test tulajdonságaival.

télleg progmatos vagyok. máshol ilyeneket nem tanítanak? itt szerintem eléggé sokmindenbe túlságosan is belemennek, annyira, amennyire nem lenne már indokolt.
a linket köcc, olvasgatom.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#139
elfelejtettem: nem tudod, hol találok még ezzel kapcsoatos infót?

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#138
"az 16 elem,és 4 dimenzió.(pontosabban a mátrix rangja 4).
"
a 4 times 4 -es mátrix 16 dimenziós vektortér.

"A third personokban használt matematikai mõódszer a quaternions.(pontosabban ez ugyanolyan szátest mint a valós v. komplex számok,csak 3 imaginárius+1 valós tagot tartalmaz. 2i+1v-re nem lehet algebrát építeni.)"
ferdetestet alkotanak a kaverniók, hogy pontosak legyünk.
és ilyan célú felhasználásukról még nem hallóttam. még csak robotvezérléssel kapcsolatban találkoztam vele.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

Omegared
#114
Kedves I96.

1.
TFH. (tegyük fel hogy) adok neked kerek perec 2* kb 35 ezer kemény valutát, Magyar Forintot.
TFH. van két felsõ-középkategóriás alaplapod, mondjuk MSI, vagy felsõ kategóriás Asus (nem az "X-X"-el végzõdõ típusú).

Siess el a sarki számtecheshez, nagy bociszemekkel nézz a bácsira, és kérj tõle 1 AMD, és 1 Intel processzort. A leggyorsabbat ami kijön a körülbelül 35e HUF-ból.

A Ebolt árait vettem alapul, kétségtelen hogy van olcsóbb is, de ez elég ismert (ellenõrizhetõ).
Mindazonáltal az olcsóbb helyeken arányosan olcsóbb mindkét általam kiválasztott processzor.
és sajnos sok tapasztalatlan ember vásárol náluk, és a mögöttuk álló nagykertõl is.

Nézzük az Intel oldalt.

Intel Celeron 478PGA 2700MHz BOX
(128KB, 400Mhz-Northwood)
Ára: nettó 26.640 Ft (bruttó 33.300 Ft)

Amd oldal:

AMD XP 2500+ CPU (1.83GHz, 512KB, 333MHz)
AXDA2500-Barton

Ára: netto 24.880 Ft (brutto 31.100 Ft)
Venti nincs, + 2-4e HUF.


Namost ugorj neki, telepíts, installálj (legyen mindkét gépben ugyanolyan videokártya, ugyanolyan memória (512mb 400DDR) 80Gb Seagate Barracuda IV. vinyó, stb.


Kedvenc mondásod az órajel vita, és hogy az összteljesítmény a lényeg.

1830 Megahertz áll az Intel 2700 (!) Megahertzével szemben.
Hol van itt a PR számokkal való dobálódzás? 2500+ ez van írva a procra.

Tesztek szerint (saját tapasztalat is), nézz szét nyugodtan az interneten, a 2500+-os Amd, gyorsabb mint a 2700mhz-s Intel Celeron.

Ehhez a ponthoz érve jön az a duma hogy ne egy cerkához hasonlítsam az Athlont.
De ehhez fogom hasonlítani, mivel kis országunkban az ÁR a döntõ tényezõ, és sokan így választanak központi egységet gépükhöz.
Ár-érték viszonylatban messze az Amd processzorai jelentik az optimális megoldást.

Valamint megkérnélek még arra hogy mutass nekem egy programot ami nem megy az AMD platformon (mondjuk én csípõbõl mondanék néhányat, de ezek mind vagy Intel platformot tesztelõ programok, vagy az Intel platformhoz való fejlesztõi eszközök.).
A haverom haverjának régi szobatársa duma nem kell.




2.
Hányadik neved ez (lehet én emlékszem rosszul )?
Egy dologból rád ismertem. Az a bizonyos eset (vagy korábbi sérelem) azzal a K6-os procival… Mindig mikor valami hasonló vita kerekedik itt te biztosan megjelensz…


Üdv.: Omegared

[HUN]PAStheLoD
#100
jó kis topic majd talán írok is bele ha lesz idõm ;]

hátö .. az elõzõ aláírásom sokkal jobb volt :]

Dikkma
#95
Jó volt végigolvasni mindezt :)
Dikkma
#94
Igen, mert lámák. Sokmhz, intel.
#93
Gyakorlatilag semmi, a lényeg a hirben van...
mir
#91
"Viszont arra elfelejtettel ravilagitani hogy a 2 procinak nemcsak az orajele, de a savszelessege is igencsak kulonbozo."
errleváns.
rendszereket vizsgálunk.
a rendszerekbe meg beletartozik a sávszélesség is.

"Nem. Pont azert mert nem osszemerhetoek. Esetleg a repulot meg a veto"magot nem kene osszehasonlitani?"
mi az hogy nem összhasonlítható? ha a kérdéses feladatokat el lehet végezni mind a kettõn, akkor össze lehet hasonlítani.

"Jo, akkor adj ossze mind2vel 2 szamot. Ja, hogy az agy lemaradt? Hat akkor meg is cafoltad sajat magad..."
le kellene szokni az általános "teljesítmény" szó használtaáról, és a teljesítményt egy bizonyos dologgal kapcsolatban kell vizsgálni.
én nem azt mondtam, hogy az agy mindeben gyorsabb, hanem azt, hogy az egy az említett dolgokban jóval gyorsabb. az összeadásról nem szóltam. egy példa nem támast alá egy feltevést, de egy ellenpélda megdönti.


AMDs rozsa: az órajel nem minden.
ennek ellenkezõje: az órjel minden.
az XYos példád ferde.

mind1.
én kiszálltam, flamelni nincs kedvem.
hi mindenki.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

RelakSfromhome
#90
Ennyi szart végigolvasni nincs gyomrom.
Valaki összefoglalná, hogy mi is történt a hozzászólások között?

VIP regem 05.14-én lejár. Akkor elbúcsúzom mindenkitõl, és továbba csak mint RelakS leszek jelen :)

mir
#88
"Csak arra akarok kilyukadni hogy semmi értelme a RISC vs CISC-nek. Mára jórészt ötvözödtek ezek a technikák"
ezzel kapcsolatban meggyõztél.
de szerintem attól függetlenül a processzorok architektúrájának jellemzésére még most is alkalmas a CISC/RISC páros.(meg van még sok, pl. VLIW EPIC vektor MISD bit-slice stb... de ezeket most hagyjuk)
azonkívül nem lehet elkezdeni úgy tanulni a számítástechnikának ezen részét, hogy :
vannak itt ilyen foglamak, tanuljátok meg õket, mert ezek nélkül nem lehet csinálni semmit, de azért tudjátok, hogy ez ma már mind hülyeség...

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#87
Az agy példát azt csak egy érdekes nézõpontként említettem meg.
és lehet, hogy összeadni nem tud, de arra amire tervezték akkor is KATEGÓRIÁKKAL gyorsabb, mint akármilyen más processzor, pedig minden egysége jóval jóval lassabb.
a célom nem az volt, hogy összehasonlítsam most a két "processzor" teljeyítményét, csak az, hogy rávilágítsak, hogy egy lényegesen alacsoníabb órajelû "processzor" is lehet speciális feladatokban SOKKAL SOKKAL gyorsabb, mint egy jóval magasabb órajelû, észerintem az állításomat bizonyítottam, az általam említett dolgokban az agy valóban gyorsabb, az "alacsonyabb órajel" ellenére.
abban is megegyezhetünk, hogy nem ugyan arra jó, de az állítást, miszerint NAGYON kicsi órajelû "processzor" is lehet gyorsabb, mint akármilyen nagy órajelû társa bizonyítottnak tekinthetjük.
ja, és mielõtt azt mondanád: nem fair az összehasonlítás: már miért nem lenne fair? adott feladatok elvégzésére való alkalmasságot lehet vizsgálni. az sem érv, hogy az agy nem 32 bites. mert akkor mi van? semmi.

"Hiaba szajkozod folyamatosan az amd PR rizsajat, attol meg nem lesz igaz"
ha te azt állítod, hogy az AMD féle PRT rizsa nem igaz(márpedig egészen egyértelmûen azt állítod a fenti mondatban) akkor az azt jelenti, hogy szerinted annak az ellenkezõje igaz, azaz az órajel a teljesítménnyel szoros kapcsolatban van.ezt több pontos is meg lehet cáfolni:
1: agy. bár ezt hagyjuk úgy látom, a lényeget nem sikerültmegértetnem.
2: vegyünk egy kripto processzort. ezek tipikusan 500 MHz alatt vannak, de a kódolási teljesítményük SOKKAL alacsonyabb, mnt az általános célú processzoroké.
tehát megint: lehet nagyobb teljesítményt adni kisebb órajelen.

ps: lehet, hogy ez eddig félreérthetõ volt: az általános célú processzor nem azt jelenti, hogy mindenre jó, hanem azt, hogy elágazásokkal és ugrásokkal teli "viszonylag" kisebb számításigényû programok futtatására vannak tervezve. tehát ezek is speciálisak egy bizonyos szinten.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#82
van egy tippem: a tippem az, hogy míg régen a bonyolult része a processzoroknak a végrehajóegység volt, ma meg már mondhatjuk, hogy a "körítés" a bopnyolultabb.
ezzel egyetértek.
de ez nem azt jelenti, hogy CISCet csinálni jobb. az azt jelenti, hogy a RISC elõnye csökkenni látszik.
erre megoldás lehet a VLIW vagy az EPIC, de... hát mondjuk úgy hogy a megfelflõ fordító nagyon nagyon hiányzik. pedig az intel 9 éve szenved vele.
arról meg nem is beszélve, hogy a jó fordító még csak szükséges feltétele lenne az ilyen processzorok sikerének, de távolról sem elégséges.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#81
ezekkel az idézetekkel mire akarsz kilyukadni? i can't see the point.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#80
errõl a kersztlicenc megállapodásról tudtam, de amikor én olvatam még szinte minden 7pecsétes titok volt, nem lehetett tudni, hogy mi mindenre terjed ki, a SSE utasításokat emlegették csak példaképp.

"6 es a p1 meg mukodtek azonos alaplapban igy nemhiszem hogy hw felé kulonbozo keppen viselkedtek"
a mkrokód az X86 utasítások alatti szint, a processzor sosem hagyják el makroutasítások, makroutasítások AMDnél CACHE-be sem kerülnek(a P4nél az L1 cache makroutasítás cache) tehát a makroutasítások sosem hagyják el a processzort.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#76
"bár be kell vallanom és is elõszõr a Tanenbaum-féle Architekturák könyvben olvastam errõl"
én is ott olvastam, és onnan emlékeztem a P PRO RISC felépítésére is. nos, az emlékeim fakulnak, úgy tûnik...

"egyébként az Intel és az AMD procik _nagyjából_ ugyanazt tudják, már csak azért is mert az AMD licenszeli a Pentiumok mikrokódját"
nem a 386 volt az utolsó, amit az inteltõl licencelt? azt hiszem azóta sajátot használnak.
a makrokód meg egészen biztos különbözik, mert az nagyon szorosan a HW-el szimbiózisban mûködik, az egészen biztos, hogy nem azonos.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#75
a CELL az vektorprcesszorok egy lapkán. a SPEC értékei(a terrflops is az) nem összehasonlítható egy általános célú processzor hasonló értékeivel.
és a probléma ezzel a megközelítéssel van.
a processzort nem úgy kezdjük el felépíteni, hogy hány tranzisztorból mennyi mndent tudunk építeni.
elárulok egy nagy titkot: a processzorok teljesítményét az elmúlt 2-3 évben leginkább a központi memória hatalmas késleltetése okozta, és ahogy az idõ halad egyre inkább ez fogja a korlátot jelenteni az általános célú processzoroknál. mégegyszer mondom a CELL egy többmagos vektorprocesszor, ezért ott a memóriakésleltetés(architektúrából adódó okok miatt) jelenleg alig jelent problémát.

"ha azt vesszük hogy egy normális RISC procit 2-3 végrahajto egységgel fel lehet épiteni 4-5 millio tranzisztorbol, fpu-val , meg vector egységgel ki lehet simán hozni 7-8 milliobol"
FPUs SIMG egységes vektorprocesszor építettek már 500 000 tranzisztorból is, meg építettek már 20 000 000ból is. tervezésnél az adja meg az alapot, hogy mire akarják a processzort használni, kell-e, hogy valamivel komptaibilis legyen, mennyire lehet behatárolni a felhasználást, mennyire kell, hogy általános célú legyen. 7-8 milió tranzisztoból akármit ki lehet hozni.

"és ez kb pörögne 500-1500 MHZ-en"
na ez az, ami télleg... érdekes kijelentés.
a skálázódás a processzorokkal kapcsolatban a legszeszéjesebb dolog.
amikor elkezdik tervezni a processzort, akkor megcélozhatnak egy órjeltartományt, és miután a proci mûködõképes lesz, neki lehet állni, és különbözõ steppingeketz készíteni hozzá, hogy növeljék az órajelet.
+ péld. a SUN az ultrasparcII processzorát 100-250 MHz közé szerette volna belõni. ezzel szemben a processzor nagyon jól sikerült, és 133 MHz lett a leglassabb belõle. nagyon jól lehetett skálázni, és a különösebb erölködés nélkül is kijött belõle az 533 MHz.
-példa: az AMD a K6ost 750 MHz-ig szerette volna vinni(bár a tervezést nem õk kezdték meg, akkor vásárolták fel a fejlesztõ céget, amikor a proci félkész volt) de az istennek sem tudtak 50 MHz fölé menni.
lehetne -példaként melíteni az összes MIPS processzort, azok mindíg kevesebbet mentek, mint amennyire tervezték õket(persze ennek ellenére is félelmetesen gyorsak voltak mindenféle grafikai és CAD alkalmazást tekintve)
tehát arra, hogy egy proci mennyit pörög akkor lehet tippelni, ha kész van. tervezni lehet, hogy mennyit pörögjön, de az csak irányszám, hogy annyit szeretnének.

"és egy chipre ha ráintegrálnának kb 10 ilyet ami lenne olyan 70 millio plusz a cache 50 millio
az még mindig csak 120 millio tranyo a p4 tudtommal többöl áll"
RISC processzort nem terveznek így. mégegyszer mondom a CELL vektorprocesszor, nem RISC.

"akkor szerintem ezt magyarázd meg az IBM , toshiba, sony mérnökeinek akik a következö generácios processzort ilyenformán tervezték meg
ja és 1 teraflops lesz :D"
nem kell enkik elmagyarázni.
a következõ generációs processzor kifejezés nem helyénvaló, mert a CELL semminek sem a következõ generációja semmilyen tekintetben. ha minden processzor következõ generációjára akartál célozni, akkor i kell hogy ábrándítsalak: a CELL nem fog kitörni a szórakoztató-elektronikai eszközökbõl. esetleg kripto-processzorként alkalmazhatják majd, vagy 1-2 spec. mûveletet tudnak elvégezni. de az IBM is nagyon serényen fejleszti a következõ generációs POWER processzorát.
azok a cuikkek, amelyekben összehasonították a CELL16 és a Deep Blue teljesítményét... nos azok a cikkeket az IBM PR dolgozóinak a dícséretére válnak, mert elhitették az emberekkel, hogy õk most egy szuperszámítógépet építettek egy chipbe. ami -hogy ismételjem magamat- nem igaz. a deep blue általános célú szuperszámítógép, a SPEC eredményei (terrflops) csak a lebegõpontos számítási teljesítményét jellemzik valamilyen szinten.
ha azt a bizonyos sakkprogramot nézzük, ami egyszer megvert kasparovot, majd kikapott tõle egy párszor, nos az a CELLen valószínûleg kisebb teljesítményre lenne képes, mint egy tisztességesebb(2processzoros) PC. merthogy(tudom, uncsi) a CELL nem általános célú processzor.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

#72
"ha azt vesszük hogy egy normális RISC procit 2-3 végrahajto egységgel fel lehet épiteni 4-5 millio tranzisztorbol, fpu-val , meg vector egységgel ki lehet simán hozni 7-8 milliobol
és ez kb pörögne 500-1500 MHZ-en"
ez hülyeség.

"és egy chipre ha ráintegrálnának kb 10 ilyet ami lenne olyan 70 millio plusz a cache 50 millio
az még mindig csak 120 millio tranyo a p4 tudtommal többöl áll"
ez ha lehet még nagyobb
p4: ~40milió tranyó
de ezt leszámítva is... vajyon hol tanítanak olyan dolgokat, amikbõl valaki ilyenre következtet?
legyen elég annyi, hogy ez baromira nem így megy."


akkor szerintem ezt magyarázd meg az IBM , toshiba, sony mérnökeinek akik a következö generácios processzort ilyenformán tervezték meg
ja és 1 teraflops lesz :D

Mi van, bamba paraszt, még most sem buzog föl benned Árpád vére?” (McSzéchenyi)

mir
#71
"amugy az Intel procik már 486-os koruk óta tartalmaznak egy belsõ RISC magot"
én úgy tudtam, hogy az EV a következõ volt:
386 RISC beütésõ FPU(co processzor)
486: FSB
pentium: pipeline
pentium pro/II inside RISC.
a 486 még nem volt belül RISC

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#70
"The Advance Dynamic Execution engine is a very deep, out-of-order speculative execution engine that keeps the execution units executing instructions. The Pentium 4 processor can also view 126 instructions in flight and handle up to 48 loads and 24 stores in the pipeline. It also includes an enhanced branch prediction algorithm that has the net effect of reducing the number of branch mis-predictions by about 33% over the previous P6 generation processor's branch prediction capability. It does this by implementing a 4-KB branch target buffer that stores more detail on the history of past branches, as well as implementing a more advanced branch prediction algorithm."
OK.

"# Nine-issue superpipelined, superscalar x86 processor microarchitecture designed for high performance
# Multiple parallel x86 instruction decoders
# Three out-of-order, superscalar, fully pipelined floating point execution units, which execute x87 (floating point), MMX™ and 3DNow!™ instructions
# Three out-of-order, superscalar, pipelined integer units
# Three out-of-order, superscalar, pipelined address calculation units
# 72-entry instruction control unit
# Advanced hardware data prefetch
# Exclusive and speculative Translation Look-aside Buffers
# Advanced dynamic branch prediction"
ezt pontosan hol találtad?
Ez ellentéts azzal, amiket eddig olvastam, szeretném átnézni az anyagot, mert ez érdekel.
elõre is thx.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#67
mert nincs is sok kapcsolat. a manapság terveezett processzorok esetéb általában felelhetõ kapcsolat az órajel és a teljesímény között.
mostanában olvastam, hogy egy angol kutatócsoport az agyat mint számítógépet:
bológiai elven mûködik
~10 000 000 000 egységbõl épül fel
kb 50-60Hz az "órajele" általában
asszinkron
bizonyos részei jóval "gyorsabbak"(max 20000 Hz)
és ezzel a relatíve kis "órajelû" asszinkron procival:
-valós idejû 3D-s képfeldolgozás
formafelismerés
tanulás
hangfelismerés
hanggenerálás
bonyolult mozgáskoordinálás a 3D-s térben
logika(!)
ez szerintem egy elég érdekes megvilágítása a dolgoknak, és nekem nagyon tetszett. hátha másnak is...

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#65
"The facts speak for themselves."
a hülye biztosan én vagyok, de még mindíg nem látaom a kapcsolatot a P4 meg egy pénztárgép között, sorry...

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#64
"Velemenyem szerint eppen attol CISC proci hogy hardveresen benne vannak olyan dolgok mint pl mmx sse stb... A risc-ben pedig csak az altalanos celu ALU van de az van felturbozva. Amirol te beszelsz az szerintem a mikroarchitektura es a mikrokod. Egy gepi kod tobb mikrokodbol all.
Szoval mint emlitettem attol meg hogy mikrokodot hasznal nem neveznem risc-nek a belsejet. Es a risc procikban is van mikrokod.."
a CISC és a RISC közötti különbség teljesen független mindenféle SIMD egységtõl
CISC/RISC:
utasítások száma:
200+/max50
regiszterek száma: kevés/sok
nagyjából ez az a két dolog, ami a legfontosabb.
nem az MMXtõl, meg az SSEtõl lettek a pentiumok CISCek.
meg kell hogy jegyezzem, az IBM POWER4ben, G5ben, SUN USIIIban és sun USIIIiben is vannak SIMD egységek, pedig ezek tényleg igazi echte RISC processzorok kívül belül.

Ha valakit kicsit komolyabban érdekel ez a téma, akkor van itt egy elõadástervezet, amiben találhat érdekes dolgokat. mondjuk a CISC/RISC közötti különbségek épp nem szerepelnek benne, de sokminden más igen.
http://praetor.web.elte.hu/procv3.ppt

"Figyu, én eddig úgy tudtam hogy az x86-os utasítások felcserélése az új P4-eseknél igenis megengedett (pl. ha van egy MOV EAX,EBX és utánna egy MOV EDX, 8 akkor azok felcserélõdnek)."
Nos a P4el akpcsolatban nincsnek konkrét ismereteim, de a K7 egészen biztosan nem cseréli fel az utasításokat, és én úgy tudtam, hgy az X86 is alapjában véve nagyon kötött utasítássorrendû.
az ilyen példáskat, mint amiket te mondtál a fordítónak nem szabad bele tenni, aki meg ASMben programozik, az meg ne csináljon ilyet.
de a P4 lehet, hogy játszik ilyen felcsrélõst, majd ha lesz idõm(vizsgaidõszak után) utánanézek.
és remélem senkinek sem gázoltam a lelkébe, ha igen, nem volt szándékos.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

HuAn82
#63
Így van!

\"És cselekszem rajtok nagy bosszúállásokat fenyítõ haragomban, hogy megtudják,hogy én vagyok az Úr,ha bosszúmat állom rajtok.\" Ezékiel 25, 17

HuAn82
#62
"Lehet, hogy értesz a számítástechnikához és most itt mindenkit le akarsz alázni , de a helyesírásban nagyon nem vagy otthon!"

\"És cselekszem rajtok nagy bosszúállásokat fenyítõ haragomban, hogy megtudják,hogy én vagyok az Úr,ha bosszúmat állom rajtok.\" Ezékiel 25, 17

HuAn82
#61
"Lehet, hogy értesz a számítástechnikához és most itt mindenkit le akarsz alázni , de a helyesírásban nagyon nem vagy otthon!"

\"És cselekszem rajtok nagy bosszúállásokat fenyítõ haragomban, hogy megtudják,hogy én vagyok az Úr,ha bosszúmat állom rajtok.\" Ezékiel 25, 17

#60
Mir:

Figyu, én eddig úgy tudtam hogy az x86-os utasítások felcserélése az új P4-eseknél igenis megengedett (pl. ha van egy MOV EAX,EBX és utánna egy MOV EDX, 8 akkor azok felcserélõdnek).

Csak azt szeretném kérdezni hogy 100%-ig biztos vagy benne hogy nincs ilyen?

mir
#56
"Sok tanulmany keszult mar errol, es sok vita is volt mar hogy melyik jobb, a cisc vagy a risc;
Amint latod a cisc lett a sikeresebb. Nem feltetlenul a sebessege miatt de pl gazdasagi okokbol egyertelemuen."
a RISC mondható sikeresebbnek.
a mai "CISC" processzorok (pentiumok,K6, K7, K8) már kíbvül cisc, belül RISC processzorok, ami azt jelenti, hogy a bonyolultabb utasításokat több egyszerû belsõ utasításra bontja le a processzor.
így mivel CISC processzort gyakorlatilag 7-8 éve nem gyártanak akár a RISCet is tekinthetjük nyertesnek.

"Egyebkent a cikk nagyonjol ramutat a jelenlegi "trend" hatranyaira. Az ilyen jellegu (hosszab futoszalag) orajel novelessel exponencialisan kevesebb teljesitmeny novekedes erheto el.
Hiaba ketszer nagyobb az orajel, a teljesitmeny kozelsem fog ennyivel novekedni, nemugy mint a tranzisztorok szama vagy a teljesitmeny felvetel.
Ez egy ido utan mar gazdasagilag sem fogja megerni, oriasi raforditott koltsegert csak minimalis novekedest erunk el.
A mennyiseg noveleserol at kene mar terni a minoseg novelesere. Utobbinak sokfele megvalositasa lehetseges, pl architekturalis modositasok.
Ezenkivul vannak teljesen mas jellegu megoldasok is pl Aszinkron processzorok, ahol tudniillik nincs orajel, igy az orajel okozta megkotesek sem ervenyesek."
ezzel egyet értek, de van valami tanulmány, amit valami okos ember írt(nálam legalábbis sokkal okosabb) és az a tanulmány az iparba elfogadottnak számít, komolyabb ellenvélemények nélkül
ennek a témája az, hogy hogy a processzorok teljesítménynövelésének alapjábanvév két útja van:
1: hosszú pipeline, és magas órajel
2: rövid pipe, és alacsony órajel.
a tanulmány hosszú távon egyértelmûen az 1. megoldást hozza ki jobbnak.
bár az, amit az intel csinál még szerintem nem az elkerülhetetlen technológiai korlát miatt van(mint amirõl az elemzés is szól) hanem az idióta PR részleg mûveli...

"Mir!

Lehet hogy értesz a számítástechnikához és most itt mindenkit le akarsz alázni , de a helyesírásban nagyon nem vagy othon!"
tudom, hogy szarul gépelek.
és nem akartam mindenkit lelázni, de akkor nem is fogok.
jócakát.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#51
inkább el sem kezdem mondani, hogy... reménytelen esetekre most nincs 60 percem.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#50
"ha azt vesszük hogy egy normális RISC procit 2-3 végrahajto egységgel fel lehet épiteni 4-5 millio tranzisztorbol, fpu-val , meg vector egységgel ki lehet simán hozni 7-8 milliobol
és ez kb pörögne 500-1500 MHZ-en"
ez hülyeség.

"és egy chipre ha ráintegrálnának kb 10 ilyet ami lenne olyan 70 millio plusz a cache 50 millio
az még mindig csak 120 millio tranyo a p4 tudtommal többöl áll"
ez ha lehet még nagyobb
p4: ~40milió tranyó
de ezt leszámítva is... vajyon hol tanítanak olyan dolgokat, amikbõl valaki ilyenre következtet?
legyen elég annyi, hogy ez baromira nem így megy.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

#49
érdekes lehetett :)))))))

#48
azt nem értem mért kell eröszakolni a MHZ-eket mikor van sokkal jobb megoldás a teljesitmény novelésére
ha azt vesszük hogy egy normális RISC procit 2-3 végrahajto egységgel fel lehet épiteni 4-5 millio tranzisztorbol, fpu-val , meg vector egységgel ki lehet simán hozni 7-8 milliobol
és ez kb pörögne 500-1500 MHZ-en
és egy chipre ha ráintegrálnának kb 10 ilyet ami lenne olyan 70 millio plusz a cache 50 millio
az még mindig csak 120 millio tranyo a p4 tudtommal többöl áll
ennek a teljesitménye ugy lealázná a p4-et hogy öröm lenne nézni

Mi van, bamba paraszt, még most sem buzog föl benned Árpád vére?” (McSzéchenyi)

mir
#47
"Kesz szerencse hogy ilyen "tajekozott" vagy, a penztargep nem veri esetleg a P4-eket?"
explain, specify please.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#45
AAA 37h VectorPath 6
néhány példa ömlesztve kimásolva:
az utolsó szám a végrehajtási idõ.
AAD imm8 D5h VectorPath 6
AAM imm8 D4h VectorPath 16
AAS 3Fh VectorPath 6
ADC mreg8, reg8 10h 11-xxx-xxx DirectPath 1
ADC mem8, reg8 10h mm-xxx-xxx DirectPath 4
ADC mreg16/32, reg16/32 11h 11-xxx-xxx DirectPath 1
ADC mem16/32, reg16/32 11h mm-xxx-xxx DirectPath 4
BT mem16/32, imm8 0Fh BAh mm-100-xxx DirectPath 4
BTC mreg16/32, reg16/32 0Fh BBh 11-xxx-xxx VectorPath 2
BTC mem16/32, reg16/32 0Fh BBh mm-xxx-xxx VectorPath 9
BTC mreg16/32, imm8 0Fh BAh 11-111-xxx VectorPath 2
BTC mem16/32, imm8 0Fh BAh mm-111-xxx VectorPath 6
BTR mreg16/32, reg16/32 0Fh B3h 11-xxx-xxx VectorPath 2
BTR mem16/32, reg16/32 0Fh B3h mm-xxx-xxx VectorPath 9
BTR mreg16/32, imm8 0Fh BAh 11-110-xxx VectorPath 2
BTR mem16/32, imm8 0Fh BAh mm-110-xxx VectorPath 6
BTS mreg16/32, reg16/32 0Fh ABh 11-xxx-xxx VectorPath 2
BTS mem16/32, reg16/32 0Fh ABh mm-xxx-xxx VectorPath 9
BTS mreg16/32, imm8 0Fh BAh 11-101-xxx VectorPath 2
BTS mem16/32, imm8 0Fh BAh mm-101-xxx VectorPath 6
CALL full pointer 9Ah VectorPath 18
CALL near imm16/32 E8h VectorPath 3 2
CALL near mreg32 (indirect) FFh 11-010-xxx VectorPath 4
CALL near mem32 (indirect) FFh mm-010-xxx VectorPath 4
CALL mem16:16/32 FFh 11-011-xxx VectorPath 19
CBW/CWDE 98h DirectPath 1
CLC F8h DirectPath 1
CLD FCh VectorPath 1
CLI FAh VectorPath 4
CLTS 0Fh 06h VectorPath 10
CMC F5h DirectPath 1
CMOVA/CMOVNBE reg16/32, reg16/32 0Fh 47h 11-xxx-xxx DirectPath 1
CMOVA/CMOVNBE reg16/32, mem16/32 0Fh 47h mm-xxx-xxx DirectPath 4
CMOVAE/CMOVNB/CMOVNC reg16/32, mem16/32 0Fh 43h 11-xxx-xxx DirectPath 1
na most ennyi is elég lesz.
érdekesség:
CMPXCHG8B mem64 0Fh C7h mm-xxx-xxx VectorPath 39
CPUID 0Fh A2h VectorPath 42
DIV mreg8 F6h 11-110-xxx VectorPath 17
DIV AL, mem8 F6h mm-110-xxx VectorPath 17
DIV mreg16/32 F7h 11-110-xxx VectorPath 24/40
DIV EAX, mem16/32 F7h mm-110-xxx VectorPath 24/40
ENTER C8h VectorPath 13/17/19/22 6
IDIV mreg8 F6h 11-111-xxx VectorPath 19
IDIV mem8 F6h mm-111-xxx VectorPath 20
IDIV mreg16/32 F7h 11-111-xxx VectorPath 26/42
IDIV EAX, mem16/32 F7h mm-111-xxx VectorPath 27/43
vannak tényleg sok idõ alatt végrehajtható utasítások.
és itt az INT pipe 10 lécsõ, a FPU meg 12.
az utolsó oszlopban található száot ennyivel kell megszorozni, hogy megkapjuk az utasítás végrehajtásának kezdete, és vége között eltelt idõt.
és akad azér ilyen is:
INVLPG 0Fh 01h mm-111-xxx VectorPath 106

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#43
épp ellenkezõleg!
a legtöbb utasítást fel kell bontani, alig marad 1 órajeles utasítás.
épp most olvastam bele a K7 barton opt. guideba, és az utasítások 25%a 1 órajeles, az összes utasítást tekintve pedig az átlag 3.5-4 körül van. ha érdekel, akkor aqz AMD oldalán megtalálod az opt.giuideot, elég sok érdekes dolgot lehet benne olvasni, ha az ember végigbogarássza.
megjegyzés: a pentium4 makrokódja alapjában véve kevesebb utasítást használ úgy tudom, és így adott x86 utasítást több makroutasításra kell bontania.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#39
ps. nekem is AMDm van, mert most azt tartottam jóbb vételnek.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#37
és az SSE meg 3DNOW! meg MMX egységek nem vektorprocesszorok, hanem SIMD egységek. a vektorprocesszor processzor, sz SSE meg az MMX meg a társai feldolgozóegységek.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#36
"NEm veletlenul csak 500 mhz-esek, 64 vagy 128 bites prociknak meg az orajele nem lehet akkora mint 1 32 bitesnek. Valamit valamiert. Nem CSAK az orajel szamit, de az IS szamit, nem kene a nagy "divatos" intel suxxolas kozepette atesni a lo' masik oldalara!"
a bitek számának, és az órajelnek ha lehet még kevesebb köze van egymáshoz, mint az órajelnek meg a teljesítménynek, errõl biztosíthatlak.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#35
ezzel a bitezéssel villámgyorsan álljatok le, mert nem nagyon tudjátok mit jelent, a flamenek meg nincs értelme.
zzeb: a vektorprocesszorok nem azért vektorprocesszorok, mert több1000 bitesek, egészen más felépítésûek. a vektorprocesszorok sem szoktak több, mint 60 vagy 128 bitesek lenni, de az utóbbi is ritka már.
a vektorprocesszorokból azok a részek vannak kihagyva, amelyek nagyban visszafoják a teljesítményt: elágazások.
azokat egy külön rész vezérli, esetleg külsõ processzor. meg persze van még egy halom különbség, de könyveket lehet írni róla, én meg ma este épp nem terveztem, hogy belekezdek ilyenbe.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#34
"Ahogy ez elõttem szóló is mondta, és válaszolva az elsõ igencsak INTEL párti hozzászólónak"
pls. olvasd végig a topicot mielõtt reagálsz. elmondom mégegyszer.
a gondolat is távol álljon tõlem, hogy bármilyen szinten az intellel szimpatizálja.
a cikkel kapcsolatban fogalmaztam meg az észrevételeimet, és nem a cikk témájához szóltam hozzá.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#32
az eredeti SOLT1es K7ben, aminek most nem jut eszembe a neve ez igaz volt:
a DIE 20%a csak vezeték(egységek között)
kb 25% prefetch és függõségvizsgálat
10% elágazásbecslés.
a maradék 45% volt az L1 cache, meg az effektív utasításvégrehajtár, regiszterek, stb...

"Elnézést, hogy közbeszólok, de valóban létezik olyan, hogy utasítás késleltetés (instruction latency). Ez azt jelenti, hogy legalább mennyi idõbe telik a CPU-nak egy utasítást végrehajtása. Ez a gyakorlatban a teljes fetch-decode-execute-store mûveletsort jelenti. A Prescott esetén 30 órajelciklus, mivel ennyi lépésbõl áll a pipeline. Tehát, ha én semmi mást nem akarok kiszámoltatni a CPU-val, csak hogy mennyi 1+2, akkor az utasítás memóriából történõ betöltése és az eredmény memóriában való eltárolása között 30 órajelciklus telik el. >> Késleltetés."
ezt is tekinthetjük késleltetésnek, bár én még sosem láttam a késleltetést szót ilyen módon felhasználva, és nekem kicsit erökltettnek tûnik, mert itt feldolgozás, azaz munkavégzés zajlik, tehát ez nem késleltetés az eredeti értelemben. ez nekem új. amennyiben a cikk írója erre gondolt, meg kell, hogy kövessem ezen esetben.

a te példáddal azonban vannak problémáim:
1: a 30 lépcsõ az azt jelenti, hogy mikor a kívánt adatok már benne vnannak a regiszterbe onnantól kezdve amíg az eredmény a regiszterbe jut.
hozzávetõleg: 1 L1 cache olvasás-írás +2*1 órajelet jelent, egy L2 cache olvasás és írás +2*6 órajelet jelent és egy rendszermemóriaolvasás+írás több, mint 200 órajel(2*100+). teáht a 30 órajel az OPTIMÁLIS esetben van, és regiszterbõl regiszterbe értendõ.
itt jönnek a bonyolítások:
ha az utasítás, amit éppen végre kell hajtani fel van bontva belsõ makro-utasításokra(amire nagyon jó esély van) akkor az nem 30, hanem n*30 órajelet vesz igénybe, ahol n természesetesen egész szám.
ez azért van, mert a mai X86 procik kívül CISC belül RISC filozófia alapján mûködnek, azaz a bonyolultabb utasításokat felbontják makróutasításokra. Az X86 utasítások nagyobbik(sokkal nagyobbik) része 2, avgy több makró utasításra van felbontva, ezen esetekben a végrehajtás valamennyi*30 órajelet vesz igénybe(ilyenkor persze semmilyen memória-késletetésrõl nincs szó, a makró-utasítások teljesen rejtve vannak a programok elõl, és részeredmények nem hagyják el a processzort)

"Bocs, a 10%-ban benne van már az a rész is, ami még a végrehajtás elõtt az utasítások sorrendjét úgy rendezi át, hogy az optimális legyen a végrehajtási sebesség szempontjából. Olyan ez, mint egy jó fordítóprogram, amely optimalizálja a kódot. Csak hardveresen megvalósítva... :-)"
ez így nem igaz. a processzornak szigorúan tilos átrendezni az utasítások sorrendjét. még az is nagyon bonyolult dolog, hogy mely utasítások hajthatóak végre egyszerre. és nem azért, mert olyan nehéz ellenõrizni, hogy mely feldolgozó egységek szabadok, a függõségek, az utasítások egymásra épülése jelenti a problémát. mégegyszer: az utasítások sorrendje nagyon szigorúan meg van határozva az x86 kód esetén, semmiféle felcserélés nem megengedett.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

#25
"A másik bevett szokás az integrált gyorsítótárak méretének növelése, amely által több adatot képes helyben tárolni, ahol sokkal gyorsabb a feldolgozás és az adatátvitel is"

A cikk írója nem említi pedig érdemes lenne hogy az önmagában hogy növelik a gyorsítótárat nem feltétlen jelenti a teljesítmény növekedését ugyanis a nagyobb gyorsítótárat már valamivel lassabban tudja kezelni a CU mint kisebbet.
Aki nem hiszi járjon utána.
Pheel
#24
Ezért vezették be a PR jelölést újra. Hogy odaírhassák a nagy számokat is a dobozra. Szóval ott vannak a nagy számok az AMDnél is, mégsem viszik annyira. Szóval nem errõl van szó. Sokkal inkább arról, hogy az Intel neve nagyobb márka a fogyasztók szemében, mint az AMD neve.
dikki*yysw
#23
Az a baj, bejön nekik ez a dolog.
Múltkor volt vmi felmérés. A számítógépvásárlók 3%-a (nem 33, 93, stb) tudta, hogy mi az a MHz.
A többiek csak azt veszik ami nagyobb.

Ezért tizenx% az AMD részesedése, és alig nyereséges, mert annyiért kell adni a P4-ekkel is pariban lévõ AthlonXP-ket, mint amennyi az azonos órajelû Celeron.

Pedig.

:: http://www.behun.net :: Teh pwn Palace!™ ::

Vik1984
#22
Tipikus tavpisilesi verseny az AMDvel :-)

Néha összeszavakat a keverem

Darth Sith
#19
kettõt együtt kéne.. :)

Nem a lényeg, hanem a fontos!

#18
Bocsi: ...ezért megy el naponta...

Oldal 1 / 3Következő →