[special]

Idézet: SFIJ - Dátum: 2005. febr. 25., péntek - 19:36

mivel erdemeltem ki azt a megtiszteltetest, hogy veremet kivanod venni

Nézd. A B-középben nem lehet csak úgy ülni. Ha nem szurkolsz megfelelõen, legalább olyan, sõt nagyobb bajba kerülhetsz, mint aki  túloldalt áll.

Szerkesztette: special 2005. 02. 26. 13:19 -kor

[hvuk]

Ez eléggé meglepõ. Ha minden igaz, akkor az NVidia 350 ezer SLI chipsetet adott el eddig. Nem csoda, ha az Intel félt, hogy kimarad a buliból!

Idézet

WE GOT some interesting numbers that should boost Nvidia's financial numbers. Our knowledgeable friends told us that so far Nvidia managed to ship 350,000 Nforce 4 SLI chipsets.

That's a lot, eh? If true. When it comes to single slot graphic chipsets Nvidia managed to sell over a million Nforce 4 Ultra and Standard chipsets.

[hvuk]

Ajánlom olvasásra ezt a linuxos cikket, ami az AMD és az Intel 64 bites hatékonyságáról szól. A tesztek többségében az AMD jobban gyorsult a 64 bitre váltástól, mint az Intel, de sok olyan eset is volt, amikor az Intel lassult, az AMD pedig gyorsult. Jó kérdés, hogy ennek az oka csak az iAMD64 elégtelen megvalósítása volt, vagy pedig a fordító is közrejátszott (noha ugyanazt a fordítót használták mindkét processzorhoz). Néhány példa grafikon.

Itt volt a legdurvább a különbség (Intel lassul, AMD jelentõsen gyorsul):


Az egyetlen, ahol az Intel jobban gyorsult a 64 bittõl, mint az AMD:


A SPECViewperf alatt jobban gyorsul az AMD (az Intel általában lassul, AMD mindenhol gyorsul):

Szerkesztette: hvuk 2005. 03. 01. 19:19 -kor

[special]

Ott már régen rossz, hogy ugyanaz a compiler. Deja vu, Apple-féle teszt. Intelhez tessék Intel fordítót használni.

[SFIJ]

Idézet: special - Dátum: 2005. márc. 1., kedd - 20:54

Ott már régen rossz, hogy ugyanaz a compiler. Deja vu, Apple-féle teszt. Intelhez tessék Intel fordítót használni.

reszben van igazad. a tesztben a gcc-nek processzorspecifikus optimalizaciot irtak elo minden processzor esetere:

Gentoo x86 Install for Athlon 64: -march=athlon-xp -msse2 -O3 -pipe

Gentoo x86-64 Install for Athlon 64: -march=k8 -O2 -pipe

Gentoo x86 Install for Pentium 4: -march=pentium4 -O3 -pipe

Gentoo x86-64 Install for Pentium 4: -march=nocona -O2 -pipe

Szerintem ez korrekt volt igy, a gcc ugyanis vendor-neutralis fordito, magyaran minden processzortipusnak megfeleo modult egy kisebb szakertocsoport fejleszt. persze rdekes lett volna a linuxus icc-t hasznalni, polo: http://www.intel.com/software/products/com...clin/clinux.htm

Kb az lett vona az eredmeny, hogy az intelen gyorsit 15-20%-ot az AMD-n meg 10-15%-ot (ez szokik a tipikus lenni)

[special]

Jó, de akkor miért nem azt csinálták. Mert ez így sokak számára mocskosul nem releváns, hogy mit csinálnak a procik GCC alatt.

[hvuk]

Idézet: SFIJ - Dátum: 2005. márc. 1., kedd - 22:52

Kb az lett vona az eredmeny, hogy az intelen gyorsit 15-20%-ot az AMD-n meg 10-15%-ot (ez szokik a tipikus lenni)

Mármint a GCC-hez képest. Gondolom nem a 32 bit vs. 64 bitre gondoltál.

[h1ghland3r]

Idézet: special - Dátum: 2005. márc. 2., szerda - 9:06

Jó, de akkor miért nem azt csinálták. Mert ez így sokak számára mocskosul nem releváns, hogy mit csinálnak a procik GCC alatt.

Eppenhogy ez a relevans. A Linuxos installaciok elsopro tobbsege teljes mertekben gcc altal forditott kodot tartalmaz. Az icc ugyanis nem teljesen free, csak otthoni, non-profit felhasznalasra ingyenes. A windowsos telepitesek meg tobbnyire a microsoft forditojaval keszult kodokkal vannak teli.

Tenyleg nagyon jo az icc, de szerintem inkabb HPC celokra bir komoly jelentoseggel (egy licensz utolso emlekeim szerint 300USD).

[special]

Igen, éppen ezért aki commercial célból használja a gépet, az meg fogja fizetni a 300 dodót. Persze itt nem egy workstationre gondolok, hanem egy nagyobb gépparkra. Ha itt gyorsul az Intel-féle forgatóktól 5-10 %-ot a cucc 300 dodóért, akkor hülye lenne nem megvenni. Szintén hülye lenne egy magát komolyabban vevõ commercial softdevel nem icc-vel forgatni. Még akkor is, ha nem teljesen szabványos.

Az elméleti síkról kicsit gyakorlatiasabbá téve a dolgot, kétlem, hogy a beszúrt grafikonokon hobbiprogramokról lenne szó. Ezek kõkemény productivity benchek. Pláne azért kellett volna icc-vel csinálni, mert gcc-vel lassul az Intel néhány helyen. Namost ez azért némi validációra szorulna szerintem.

[hvuk]

Idézet: special - Dátum: 2005. márc. 2., szerda - 13:30

Az elméleti síkról kicsit gyakorlatiasabbá téve a dolgot, kétlem, hogy a beszúrt grafikonokon hobbiprogramokról lenne szó. Ezek kõkemény productivity benchek. Pláne azért kellett volna icc-vel csinálni, mert gcc-vel lassul az Intel néhány helyen. Namost ez azért némi validációra szorulna szerintem.

Az eredményekben nem az Intel vs. AMD az érdekes (az eddig is tudott volt), hanem a 32 bit vs. 64 bit a kétféle platformon. Te tehát azt állítod, hogy az Intel fordítója nagyobb gyorsulást tud elérni (64 bit vs. 32 bit viszonylatban) az Intel prociknak, mint amit elér az AMD processzoroknak? Vagy megfordítva a kérdést: azt állítod, hogy a gcc által fordított kód jobban optimalizálja a 64 bites kódot a 32 biteshez képest az AMD-re, mint az Intelre? Ez azért szvsz. elég furcsa lenne!

Szerkesztette: hvuk 2005. 03. 02. 13:32 -kor

[h1ghland3r]

Idézet: special - Dátum: 2005. márc. 2., szerda - 11:30

Igen, éppen ezért aki commercial célból használja a gépet, az meg fogja fizetni a 300 dodót. Persze itt nem egy workstationre gondolok, hanem egy nagyobb gépparkra. Ha itt gyorsul az Intel-féle forgatóktól 5-10 %-ot a cucc 300 dodóért, akkor hülye lenne nem megvenni. Szintén hülye lenne egy magát komolyabban vevõ commercial softdevel nem icc-vel forgatni. Még akkor is, ha nem teljesen szabványos.

Az elméleti síkról kicsit gyakorlatiasabbá téve a dolgot, kétlem, hogy a beszúrt grafikonokon hobbiprogramokról lenne szó. Ezek kõkemény productivity benchek. Pláne azért kellett volna icc-vel csinálni, mert gcc-vel lassul az Intel néhány helyen. Namost ez azért némi validációra szorulna szerintem.

Nem 300, hanem 400 dodo, ugy latom kozben felment az ara.

Special, te ugye nem dolgoztal meg fejlesztocegnel? Ez nem ugy megy, hogy megvesszunk egy dobozt, aztan 5-10%-ot gyorsul a cucc.

Egyreszt, ha nem akarsz nagyon sokat szivni, akkor minden fejlesztod asztalara meg kell venni, mert egy csomo dolgot nem tud a gcc, vagy a vc++, amit tamogat az icc. De ha meg az elvi feature azonossag meg is van, akkor az ilyen compiler migracio elso elmenye az szokott lenni, hogy az uj forditoval le sem fordul, vagy ha le is fordul, akkor nem mukodik jol.  Altalaban boduletes szivasok utan lehet migralni az uj forditora. Ha azt a fejlesztesi kapacitast a kodreviziora forditod, akkor lehet, hogy nyuves 5-10%-nal tobbet ki tudsz belole hozni.

Ha HPC projekted van, akkor mas a helyzet, de ott mar a kod sokszor eleve hegyezve van, es akkor minden kis teljesitmenyplusz jol jon (ezert lehet itt komolyan viritani icc-vel). Mi annak idejen CAD meg FEA  programok eseten nezegettuk az atallas lehetosegeit, de aztan elvetettek a projektet, mert nem erte meg es nagyon kockazatos volt (pedig volt ott algebrazas, numerikus integracio es egyebek, ahol jol jott volna egy kis plusz).

A magukat komolyan vevo cegeknek altalaban 10+ eves szoftverbazisuk van. Nehogy azt hidd, hogy konnyu migralni egy ekkora kodbazist. Raadasul a kovetkezo kiadasban a beigert uj feature-ok helyett csak annyi szerepel: 5-10% speedup. Sokszor egy atgondoltabb GUI megirasa is produktivabba tesz egy programot.

[hvuk]

Mióta van icc Linuxra? És mióta gcc?

[h1ghland3r]

Idézet: hvuk - Dátum: 2005. márc. 2., szerda - 13:28

Mióta van icc Linuxra? És mióta gcc?

Ez miert erdekes?

[SFIJ]

Idézet: special - Dátum: 2005. márc. 2., szerda - 10:06

Jó, de akkor miért nem azt csinálták. Mert ez így sokak számára mocskosul nem releváns, hogy mit csinálnak a procik GCC alatt.

Azert mert az icc valamiert nem tud kernelt forditani - ezert nem lehet, illetve iszonyat nehez system compilerenek hasznalni. A linuxos distro keszitok is lusta emberek, ezert nem pocsolnek vele. Ha neked valami speci app-ra van szukseged, akkor hasznalsz icc-t. Ugyanez all windowsra is. A szakma 99.999999%-ban a microsoft (watcom) compileret hasznalja, 1-2 specialista kuzdelmez csak az icc-vel..

[SFIJ]

Idézet: special - Dátum: 2005. márc. 2., szerda - 12:30

Igen, éppen ezért aki commercial célból használja a gépet, az meg fogja fizetni a 300 dodót. Persze itt nem egy workstationre gondolok, hanem egy nagyobb gépparkra. Ha itt gyorsul az Intel-féle forgatóktól 5-10 %-ot a cucc 300 dodóért, akkor hülye lenne nem megvenni. Szintén hülye lenne egy magát komolyabban vevõ commercial softdevel nem icc-vel forgatni. Még akkor is, ha nem teljesen szabványos.

megfox lepodni, de a commercial develek tobbsege gcc-t hasznal, azert mert az jol mukodik. Az intel, sun, stb compilerek nagyot tudnak villantani, de mindenfele nyavajaik vannak a szabvanyos c/c++ kodokkal - magyaran egy rakat - esetleg draga dollartizezrekert/szazezrekert megvett forrast egyszeruen keptelenek leforditanai. En mint vendor a foolproof dolgokat szeretem - de megteszem esetleg azt, hogy a termek teljesitmenykritikus reszeit osszefogom egy lib-be es azt eseteleg icc-vel forgatom le....

[hvuk]

Idézet: h1ghland3r - Dátum: 2005. márc. 2., szerda - 16:19

Ez miert erdekes?

Kíváncsi vagyok rá. Vagy speciális indokok szükségesek az ilyen ipari titkok megtudásához?

[hvuk]

Az Inquirer járt az AMD immár szokásos bemutatóján, ahol megcsodálhatták a dual-core Opteront/A64-et(?) mûködés közben, továbbá beszámolnak egy rendkívûl ocsmány kinézetû A64 laptopról is.

Idézet

AMD HAD ITS TRADITIONAL counter-IDF briefing today, and it was not all that full of new products. Last IDF it had enough dual core parts there to satisfy almost everyone, this time it had one in the display room, and a couple of other toys.

The biggest news is that the dual core parts will be fast, very very fast. If you are wondering, the first dual core parts out of the box will run at 2.4GHz, possibly more. The one show in the Alienware box below, not an Alienware product, just a cool case, was a production model. It came in a production package with a production bar code. I am pretty sure that the launch will happen early, I am just not sure how many they will put out in the first round of launches.
...

És az a bizonyos laptop:

[SFIJ]

Idézet: hvuk - Dátum: 2005. márc. 2., szerda - 14:28

Mióta van icc Linuxra? És mióta gcc?

gcc first public release: 1985
first public c++ capable relesae: 1992
first wersion with full ansi/iso C++'97 support (gcc 2.95): 1998
first version with full ansi/iso C'99 support (gcc 3.0): 2000
icc for linux first public release: 1999-2000

Szerkesztette: SFIJ 2005. 03. 02. 20:23 -kor

[h1ghland3r]

Idézet: SFIJ - Dátum: 2005. márc. 2., szerda - 19:18

gcc first public release: 1985
first public c++ capable relesae: 1992
first wersion with full ansi/iso C++'97 support (gcc 2.95): 1998
first version with full ansi/iso C'99 support (gcc 3.0): 2000
icc for linux first public release: 1999-2000

Azert az erdekes, hogy az icc 99-2000 kornyeken jott ki es most a 8.1-nel tart. Vagy nem az 1.0-rol indult?

[hvuk]

Az AMD jól befelhõsítette az eget az IDF felett.