- This topic has 60 hozzászólás, 15 résztvevő, and was last updated 19 years, 5 months telt el by
.
-
Bejegyzés
-
aty:
mindegy, letudtuk :icon_neutral:nekem amd64-en bizisten nem látszik különbség ia32,0 amd64 között sem.
de i386 csomaggal már nem foglalkoztam vagy egy éve, így nekem ez (hálaégnek) nem lehet feltûnõ – bár a KDE többek között már benne van a komolyabb igényû kategóriában (amit írtam)AMD486 wrote:a WinXP … Az is tény hogy P1-esekre (i586) állítólag nem megy fel, de lehet, hogy csak erõforráshiány miatt (pl. kevés RAM)felmegy. nekünk a számlázónk p1, és xp-t futtat 192M rammal.
„Az az igazság, hogy hiába is történik architektúrához / utasításkészlethez igazított optimalizással a fordítás, a komoly és nagy igényû tervezõ programokon kívül ebbõl szerintem sehol sem lehet profitálni. a komolyabb igényû játékok meg úgy is csak egy általános x86/ia32 illetve x86/amd64 porttal jönnek.”
Az, hogy 386, vagy 686 qurvára nem mindegy semminél. (Mivel néhány 64 bites int. regiszter, fõként lebegõpontos regiszterek használata azért már általános. Egyébként a saját – komolytalan – programjaimnak, sem mindegy. Sõt 386-on egyes ilyen regiszterek közvetlen használata miatt nem is menne. Persze szükség is van rá, mert máskülönben tetû lenne :)))) Az viszont, hogy 568 vagy 686 általában nem tûnik fel, mivel általában nem használják a lehetõségeket a programok. (Mit tudom én sse2, meg ilyenek ált. nem használatosak.)
Szóval nem az a lényeg, hogy mi, meg milyen összetett. Egy egyszerû file-beolvasó program is képes ilyeneket használni. (Kérdés az, hogy fel van-e készítve rá…)„nekem amd64-en bizisten nem látszik különbség ia32,0 amd64 között sem.”
Filemûveleteknél, fordításnál nagyon ki tud jönni a különbség (opteron esetén!!, desktop64-et nem láttam – nem is akarok túlságosan :)), viszont pl egy cd berakás egy dual opteron windowze alatt pont ugyanúgy megfog, mint egy p1-est :))). Azt viszont mesélték, hogy sempronnal igen hamar felkapaszkodik az xp… nem tudom miért.nézd én nem igazán szoktam tippelgetni, arról beszélek, amit én tapasztalok. a kettõ említett téma között egyelõre olyan kevés különbséget érzek (éreztem), hogy nem tudom azt mondani, hogy 386 és 686 csomagok és rendszerek között olyan hatalmas különsbség lenne. de mint mondtam én nem használtam i386 csomagot egy éve.
más:
ia32 ->amd64
figyelj vizsla te már használtál asztali 64 bites processzort? pl fordítás esetén a 32 bites és 64 bites cpu „ereje” a megfelelõ 64 és 32 bites rendszerek mellett is csak annyi különbséget mutat, mint amennyit a két architectúrában lévõ fpu és cu közötti különbség sejtet. szó nincs arról, hogy a 64 bites cpu 64 bites rendszerrel annyival hihetelenül gyorsabb lenne, hogy azonnal 64 bitre váltanánk tömegestül. mindezt úgy mondom, hogy már raktunk össze jónéhány amd64 alapú gépet, én is ilyet használok.Az x86_32 is meddig húzta magát?
Nagyon sok hosszú évig.
Az átállás szerintem nagyon fokozatos és lassú lesz. (illetve már az 🙂 )„nézd én nem igazán szoktam tippelgetni, arról beszélek, amit én tapasztalok. a kettõ említett téma között egyelõre olyan kevés különbséget érzek (éreztem), hogy nem tudom azt mondani, hogy 386 és 686 csomagok és rendszerek között olyan hatalmas különsbség lenne. de mint mondtam én nem használtam i386 csomagot egy éve”
386 vagy 686-os csomag lehet teljesen egyforma is… itt nem errõl van szó. Képes a lehetõségeket használni, vagy nem, akár register, akár több cpu bármi, minden lehet ugyanolyan is, és lehet, hogy óriási a különbség. Ezt a saját programjaimból is tudom.„figyelj vizsla te már használtál asztali 64 bites processzort?”
Csak mac-kel… egyébként opteront (az viszont jól duruzsolt; mondjuk más a memóra kezelés, más a teljes vas, úgyhogy…).” 64 bites rendszerrel annyival hihetelenül gyorsabb lenne, hogy azonnal 64 bitre váltanánk tömegestül”
Hát errõl szó nincsen! Ha véletlenül ezt hallattam volna. 1) Ezek a procik nem különböznek annyival, 2) átlag szoftver ellátottság hiány stb…
Az olyan helyeken jó, mint ILM, ahol számít minden csepp kakaó és ki is pengetnek ezért hw-re sw-re, mindenre megfelelõ összegeket. (No persze ott nem is az az „alap” opteron van, melyekhez mi hozzájutunk :))))ok.
ui: egy opteront én is megnéznék, de 64bites szervert még nem építettünk / hoztunk AMD alapon. sajnos.kovi wrote:mindenkinek lesz egy jele mint az oviba, aztán majd ha válaszolok, az írásom elé teszem az illetõ jelét, hogy tudja kinek megy
Nem is rossz 5let! vizsla wrote:Az, hogy 386, vagy 686 qurvára nem mindegy semminél. (Mivel néhány 64 bites int. regiszter, fõként lebegõpontos regiszterek használata azért már általános. Egyébként a saját – komolytalan – programjaimnak, sem mindegy. Sõt 386-on egyes ilyen regiszterek közvetlen használata miatt nem is menne. Persze szükség is van rá, mert máskülönben tetû lenne :)))) Az viszont, hogy 568 vagy 686 általában nem tûnik fel, mivel általában nem használják a lehetõségeket a programok. (Mit tudom én sse2, meg ilyenek ált. nem használatosak.)
Szóval nem az a lényeg, hogy mi, meg milyen összetett. Egy egyszerû file-beolvasó program is képes ilyeneket használni. (Kérdés az, hogy fel van-e készítve rá…)én egy idõben azzal voltam elfoglalva, hogy mindent cpu-ra optimalizáltam (akkor még PII celeron -om volt) és nem nagyon lehetett észrevenni, használat közben a gyorsulást, viszont mérni lehet :), szóval gyorsan mértem is (ezek igazából csak tájékoztató jellegûek, egyetlen futás, és nem csak ez a progi futott, bár cpu inteznziv alkalmazás nem, és nem is használtam közben a gépet (csak mp3 lejátszás:) )) , mivel én sem szoktam tippelgetni 🙂
(SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark)
cc -O3
Composite Score: 127.80
FFT Mflops: 21.56 (N=1048576)
SOR Mflops: 301.76 (1000 x 1000)
MonteCarlo: Mflops: 82.34
Sparse matmult Mflops: 109.40 (N=100000, nz=1000000)
LU Mflops: 123.92 (M=1000, N=1000)-O3 -march=athlon-xp -msse -msse2 -mmmx -m3dnow
Composite Score: 136.29
FFT Mflops: 20.73 (N=1048576)
SOR Mflops: 300.57 (1000 x 1000)
MonteCarlo: Mflops: 136.26
Sparse matmult Mflops: 107.11 (N=100000, nz=1000000)
LU Mflops: 116.75 (M=1000, N=1000)ugye itt i386->athlon-xp azért csak számít valamit (bár van ahol lassabb, meg van ahol mérési hibán belül lassabb:) )
-O3 -march=athlon-xp -msse -mmmx -m3dnow -mfpmath=sse
Composite Score: 137.42
FFT Mflops: 20.89 (N=1048576)
SOR Mflops: 297.08 (1000 x 1000)
MonteCarlo: Mflops: 135.57
Sparse matmult Mflops: 109.40 (N=100000, nz=1000000)
LU Mflops: 124.15 (M=1000, N=1000)az fpu „lecserélése” nem sokat segített…
-O3 -march=athlon-xp
Composite Score: 131.91
FFT Mflops: 20.22 (N=1048576)
SOR Mflops: 287.07 (1000 x 1000)
MonteCarlo: Mflops: 127.22
Sparse matmult Mflops: 105.79 (N=100000, nz=1000000)
LU Mflops: 119.26 (M=1000, N=1000)nem nagyon hiányzik a többi optimalizáció…
-O3 -march=i586
Composite Score: 127.27
FFT Mflops: 20.22 (N=1048576)
SOR Mflops: 302.95 (1000 x 1000)
MonteCarlo: Mflops: 83.89
Sparse matmult Mflops: 109.40 (N=100000, nz=1000000)
LU Mflops: 119.90 (M=1000, N=1000)kb. mint i386 esetén…
-O3 -march=i686
Composite Score: 133.72
FFT Mflops: 20.69 (N=1048576)
SOR Mflops: 284.93 (1000 x 1000)
MonteCarlo: Mflops: 138.37
Sparse matmult Mflops: 105.79 (N=100000, nz=1000000)
LU Mflops: 118.84 (M=1000, N=1000)azért csak jobb az i686…
aztán mindenki azt használ amit akar 🙂
jah:
gcc:
Thread model: posix
gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)cpu:
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 10
model name : AMD Athlon(TM) XP 2800+
stepping : 0
cpu MHz : 2071.500
cache size : 512 KB„nem nagyon lehetett észrevenni, használat közben a gyorsulást”
„nem nagyon hiányzik a többi optimalizáció…”
Hát nem csodálkozom, mert a march/mcpu (van különbség) = -msse -mmmx… stb. az összes
(Pont ez a lényeg, hogy ezeket ne kelljen végiggondolni, ismerni, alkalmazni, mert ez az opció megteszi.)
Tehát pl: sse, mmx stb mindig benne van, sse2 pedig (ha jól rémlik) nem támogatott a processzor által (Tehát vagy tudja helyettesíteni, vagy egyátalán nem mûködik a program – a pontos tünetet nem tudom.)
Az xp meg 686 cpu, tehát megint csak nem lehet különbség. (Az 586 talán csak az sse, meg a 3dnow-t nem tartalmazza – ha jól tudom – és mivel nem sokan használják, gyakorlatilag megint csak ugyanaz az eredmény.) Paraméterek nélkül pedig a fordító valószínûleg a saját processzorra fordít (vagy talán arra, amire le lett forgatva). Tehát nagy valószínûséggel 586/686 – az eredmény is ezt valószínûsíti -, tehát megint nem lesz különbség.Magyarán szólva, most megmérted a statisztikai hibát 🙂
Talán azt meg lehet állapítani, hogy az 586 ill. 868 közötti különbség az a bizonyos 6 pont. Bár ezt a talánt is félve jelentem ki 🙂 már csak ezért is ->
„(nem csak ez a progi futott, bár cpu inteznziv alkalmazás nem, és nem is használtam közben a gépet (csak mp3 lejátszás:) )))” kis kde/gnome, meg ilyesmi… nem valószínû, hogy egy szál futott.
Nem is rossz 5let! 
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz