Nagyteljesítményű UNIX/Linux munkaállomás építése

UNIX kezdő

Üdv!

Már egy ideje felvetődött, hogy le kellene váltanom öreg x86 alapú asztali gépemet. A munkámból adódóan a következő szempontok jelentek meg (nagyjából fontossági sorrendben):

-Nagy lebegőpontos számítási kapacitás (numerikus matematikai feladatokhoz)
-Erős OpenGL grafikus hardver (CAD feladatokhoz)
-Jó üzembiztoság, megbízható működés akár folyamatosan, több napig tartó maximális terhelés mellett is.
-Általános használhatóság, kompatibilitás, az általános "desktop" dolgokat is el lehessen végezni vele. (Emiatt gondolkodom azon, hogy valószínűleg valamilyen Linuxot is kellene használni rajta, talán Debiant)

A CAD-es munkaállomások (és szoftverek) csúcsát (a "közhiedelemmel" ellentétben) jelenleg a különböző RISC + UNIX/Linux rendszerk képviselik (pl: SGI, IBM Power, SUN SPARC, PA-RISC, Itanium2, stb.) Ezek közeli rokonságban állnak a nagygépes rendszerkkel, és jól is működnek együtt azokkal. (pl. néha clusterekbe vannak szervezve) Ennek megfelelően az áruk is "nagygépes", a legolcsóbbak is 800e-1M HUF körül kezdődnek, a felső határ pedig a csillagos ég. Ezért sajnos jelenleg nem áll módomban ilyesmit beszerezni.

Ezért azt gondoltam, hogy megpróbálok egy régebbi (használt) darabot beszerezni, olyat, ami a fentebb vázolt igényeimnek többé-kevésbé megfelelne. Igazából nem számít, ha mai szemel (általános használatra) ez csak egy "gyenge" gépet jelent, a lényeg az, hogy a felsorolt szempontokban megverje az x86 rendszerket, vagy legalábbis összemérhető legyen velük, de ekkor viszont legyen árban, ha lehet, olcsóbb (jobb ár/teljesítmény arány).

A problémám, hogy nem nagyon ismerem a RISC rendszereket (eddig csak néhány ilyen gépet volt szerencsém kipróbálni - egyébként eléggé meggyőzőek voltak) nem tudom mire számítsak a más architektúra miatt. Pl.: a binárisokat mennyire fogom tudni felhasználni? Egyáltalán fel fogom tudni használni őket, vagy mindent forrásból kell fordítani? A kereskedelmi (nem opensource) linux szoftvereimet, amik pl. x86-Linux kombinációban tökéletesen működnek fel fogom tudni használni? Találok az ilyen "egzotikus" hardverekhez megfelelő drivert? Ebben esetleg tud valaki tanácsot adni?

Egyébként nem ragaszkodom mereven a RISC rendszerekhez, ha jobban kijövök az ár/teljesítmény arányt tekintve egy x86-ossal, akkor az is jó. Csak a már leírt okok miatt jobbnak tűnnek. Ja, még annyit, hogy max 500e HUF-ot tudok a dologra szánni, de ha lehet, akkor (jóval :)) kevesebbet szeretnék.

ps.: bocs, hogy ide nyitottam ezt a címet, nem volt jobb ötletem, melyik kategóriába lehetne

  • 5726 megtekintés

( zwei | 2007. 01. 16., k – 08:57 )

Amit a CAD és RISC munkaállomásokról gondolsz, azzal nagyjából egyet tudok érteni, viszont nehéz dolgod lesz, ha használtan 500K körül szeretnél venni egyet, ami veri a jelenlegi x86/x64 arch. gépeket.
Újonnan egy Sun Ultra 25-ös munkaállomás kb 700K.
Ebbe ez van:
Sun Ultra 25 Workstation: 1 * 1.34 GHz UltraSPARC IIIi Processor with 1 MB on-die L2 Cache, 1 * Sun XVR-100 Graphics Accelerator, 1 GB DDR1 Memory (2 * 512 MB DIMMS), 1 * 80 GB 7200 RPM SATA Disk, 1 * DVD-Dual, 2 * 10/100/1000 BaseT Ethernet ports, 2 * Serial ports, 6 * USB2.0 ports, 2 * full-length PCI-X slots, 3 * PCI-Express slots, Solaris 10 Operating System Pre-Installed, RoHS-6 Compliant

Ezt a teljesítményt, x86 arch-ban. szvsz. olcsóbban megkapod, ha ezt használtan veszed, akkor sem kerül jóval kevesebbe.
CAD jellegű célokra szerintem a grafikus megjelenítő, és a memória mérete az elsődleges, a nyers CPU erővel szemben.

Az operációs rendszernél a választás alapja, az általad használt kereskedelmi szoftver, és annak supportja a fontos. Open source programok ebből a szempontból elég rugalmasak, de természetesen nem árt azokat is figyelembe venni. A bináris kompatibilitás elég kényes ügy, mert az leginkább csak azonos hardware architektúrán, és oprendszeren működik. Természetesen vannak különféle emulációs megoldások, de ezek mindenképpen felvetnek stabilitási és teljesítmény kérdéseket.

Ha RISC munkaállomást veszel, natív operációs rendszerrel (IBM-et AIX-el, Sun-t Solarissal) akkor annak a driver támogatásával nem lesz gond - legalábbis ha nem akarsz más forrásból extra hardvert belerakni.
Ha RISC-re linuxot raksz, azzal sem lehet túl sok gond, bár érdemes előtte tájékozódni, mert pl. Sun-ra linuxot rakni nem mindíg problémamentes.

Nem tudom, mennyire számít a munkádhoz, hogy erős RISC vas legyen alatta, de ha úgy gondolod, hogy hoszabb távon kitermeli az árát, akkor esetleg elgondolkozhatsz azon, hogy valami bérleti konstrukciót keress, ami bizonyos idő végén lehetővé teszi a maradványértéken történő megvásárlást, és így egy erősebb, drágáb vasat is meg tudsz venni.

Nos, ahogy írtam, cad ÉS numerikus matematikai/szimulációs (FEA, CFD, stb.) célra kellene. Ezért gondoltam RISC-re. Az ilyesmivel egyébként úgy vagyok, hogy erre a világ összes gépe nem lenne elég, de jelenleg még meg kell küzdenem ugye ilyen "apró" kompromisszumokra kényszerítő tényezőkkel, mint pl. az ár. :)

Az altalad leirtak a 10 evvel ezelotti szintet tukrozik.

Ma mar az x86 mindenfele fattyai (x86-64,) sokkal jobb ar/teljesitmeny mutatoval rendelkeznek, mint a RISC gepek.

Manapsag a fenti celokra valamilyen tobbprocis Opteronos/Xeonos cuccot erdemes venni. Ha nagyon szeretnel szembemenni a tomeggel, akkor meg megfontolando a dual G5-os beszerzese, leven annak eleg jo lebegopottyei vannak.

Az egyeb RISC-es cuccokba (PA-RISC, MIPS, SPARC) ezen a teren legfeljebb a nosztalgia vagy sznobsag miatt erdemes beruhazni.

Ezt nem így látom. Hadd ne kelljen már vagy negyedszer leírnom ebben a fórumban, hogy miért nem. Olvasd végig a hozzászólásokat. Különös tekintettel a vége felé fejtettem ki a véleményemet ezzel kapcsolatban.

Ami az ár/teljesítmény arányt illeti, abban valószínűleg igazad van. De a nyitó hozzászólás idevágó részei nem az ár figyelembevételével íródtak.

Egyébként köszönöm az információt a G5-el kapcsolatban. Esetleg bővebben is ki tudnád fejteni? Vannak vele tapasztalataid? Komolyan kérdezem, ugyanis már bennem is felvetődött, hogy nem lenne-e megfelelő Pl. egy Power MAC quad G5 erre a célra.

Azert nem latod igy, mert valaki, vagy valakik megetettek azzal, hogy HPC==RISC. Ez regen igy volt, valamikor a Pentium 1-2-es idejeben, de mara mar megvaltozott. Ha nekem nem hiszel, akkor nezz el a top500.org-ra. Le merem tenni a nagyeskut, hogy az ott levo gepek tobb, mint fele (x86 vagy x86-64 alapu).

Roviden a kovetkezorol lenne szo: ha nagy szamitasi teljesitmenyt akarsz, akkor ket dolgot kell nezni a processzoron:

1. Az orajelet
2. A lebegopontos egysegek szamat

Trivialisan a ketto szorzata mutatja meg, hogy mennyi muveletet tudsz maximum (elmeletileg) megoldani. Most persze lehet jonni azzal, hogy van memoriakesleltetes, meg savszel problema, de a HPC attol HPC, hogy az alkalmazasok platformspecifikus optimalizacioval CPU korlatossa valnak (a legjobb peldak erre a mindenfele numerikus kernelek BLAS, LAPACK, FFT, ...).

Gyors szamolgatas utan kiderul, hogy a PPC970, az x86 es az x86-64 jelenti a csucsot. Ha mindenkeppen ezoterikus gepre vagyunk meg idefer az IA-64, de tavaly visszavontak a workstation piacrol az Itaniumos gepeket. Talan ez is erezteti, hogy mennyire eros itt az x86 uralom.

Valahol van a neten egy benchmark sorozat publikacioja, amit a NASA keszitetett es a G5 es a Xeon osszehasonlitasat tartalmazza. Elmeletileg a G5-nek sokkal-sokkal jobbnak kellett volna lennie a Xeon-nal, ami a tesztek egy reszeben be is jott, masik reszeben kisebb volt az elony. Jelen esetben kulon hasznos, hogy a benchmarkok mindenfele HPC jellegu terhelest szimulaltak, tehat a te esetedben kulonosen relevansak.

Szoval a nagybudos igazsag az, hogy a RISC cuccok abbol eltek, hogy voltak olyan feladatok, amiket CSAK azokkal a gepekkel lehetett elvegezni (ezert lehetett oket annyira felarazni). Ma ezeknek a teruleteknek a szama erosen konvergal a nullahoz. FYI: Amit par evvel ezelott bivalyeros SGI workstationokkel csinaltak (CAD-CAM-FEA-CFD-... teruleteken), manapsag meg lehet csinalni egy kicsit combosabb dzsunka PC-vel. Meg ma is el lehet kepzelni olyan tervezesi problemat, amit csak egy nagyon specializalt RISC ws tud megoldani, de ott az exkluzivitast fizeted meg, nem igazan a teljesitmenyt.

Nem veletlen, hogy az SGI maga sem tudja eldonteni, hogy mikor megy csodbe es a tobbi RISC vendor sem a workstationobol keres sok penzt (ha megis, akkor azok x86 alapuak). A Cray kinalatban es eladasokban is az Opteronos gepek dominalnak. A kozeljovoben az egyetlen fejlesztes, ami veszelyt jelent az x86-ra, az a Sun Rock lesz, de az meg egy kicsit odebb van, raadasul nem kimondottan ws piacra keszul, hanem inkabb a szerverekre.

Anno emailban kertem tanacsot egy Sun-os sractol, hogy mit javasol linearis egyenletrendszerek megoldasara, es erdekes modon nem Sparcos, hanem Opteronos gepet ajanlott.

"Roviden a kovetkezorol lenne szo: ha nagy szamitasi teljesitmenyt akarsz, akkor ket dolgot kell nezni a processzoron:

1. Az orajelet
2. A lebegopontos egysegek szamat"

Órajel felejtő. Az órajel alapú "hype" már rég lecsengett.
Főleg akkor, ha RISC-x64 összehasonlítást csinálsz.

Jah, a RISC koruli hype meg regebben lecsengett.

Az orajel hype nem csengett le. A fenti egyszeru kepletet hasznalva nincs tul sok modod a teljesitmeny novelesere. Marad meg a magok (tehat attetelesen a vegrehajtoegysegek) tobbszorozese, de annak a hozadeka erosen ketseges, nem kis szoftveres tamogatas kell hozza. Egyszeruen arrol van szo, hogy az orajel novelesebe fektetett fejlesztesi munka hozadeka manapsag kevesebb. De lecsengesnek azert nem neveznem azt, hogy az IBM arra nyomja magat, hogy a Power6 5-6 GHz korul debutal majd. Sanki nem ugralta szet magat oromeben a quad-core intelek megjelenesere (ami duplazta a magokat), de ha hirtelen piacra dobna az Intel egy 8GHz-en operalo Xeon-t, vagy a Sun egy 4GHz-es SPARC-ot, eleg nagy ilyedelem lenne a konkurrencianal.

Tudod miert terveztek annak idejen a RISC-eket olyanra, amilyenre?
Kapaszkodj meg: azert, hogy az orajelet minel jobban novelni lehessen anelkul, hogy a procikat jelentosen at kelljen tervezni. Becsszo. Nezz utana pl. az Alpha fejlesztesenek. Mert az orajel pusztan gyartastechnologiai fejlesztesekkel novelheto (ahogy egyre vekonyabb csikszelessegre valtanak). Lasd Pentium 4 Netburst. 1GHz kornyekerol 4 GHz kornyekere jutottak (ezen a szinten) minimalis architekturalis valtoztatasokkal. Nemigen tudsz meg egy ilyen architekturat mutatni. Ja es azert a Pentiumok belsejeben is egy elegge RISC-re hajazo engine ketyeg. Hogy hogyan jutott ide az ipar az mar egy masik sztori, de ennek mar inkabb ahhoz lesz koze, hogy az Intel nem volt szegyenlos keves valtoztatassal uj procikat piacra dobni, igy ugyanannak a fejlesztesnek a koltsegeit tobb reviziora teriteni. Tobb penz -> jobb gyartastechnologia -> nagyobb teljesitmeny -> jobb eladasok -> tobb penz. Sajnos ezt a RISC vendorok nem csinaltak meg (nem tudtak felporgetni a termekciklust), igy lemaradtak.

Kicsit furcsallom az ertetlensegedet. Nem varhatod, hogy barki is valami ezoterikus ws vasarlasara fog batoritani, mert az iparban eppen az ellenkezoje tortenik. Barmelyik ertelmes v. tapasztalatokkal rendelkezo forumtars megerosithet. Gondolkozz el miert lehet ez. Ha kicsit jobban megerted, mint a mezei fanboy, akinek csak az a valasza letezik, hogy a szemetkocsogintelkinyirjaatokszupirisceket, akkor rajossz, hogy miert tukmaljuk itt neked az opteronokat-xeonokat.

Arrol mar nem is szolok, hogy egy normalis, de meg elerheto aru videokartya tamogatasa a RISC Unixokon majdnem a nullaval egyenlo (ugye az nvidia is csak x86 solarishoz ad ki drivert). Tamogatjak azt a grafkartyat, amivel eppen gyartottak az adott ws-t, de azt meg manapsag egy GeForce7600 is korberohogi. Szoval elkaparod magad CPU es grafikus teljesitmenyben is valami kodos okbol.

De erdekelne, hogy mik azok a konkret parameterek, amik alapjan elveted a javaslatokat.

Nos, azthiszem nem igazán értetted meg, amit mondani akartam. Most válasszuk szét az én problémámat, és úgy általában a különféle munkaállomásokról történő vitatkozást. Az már nagyjából nekem is világos, hogy ebben az árkategóriában, nekem jóformán csak az x86 jöhet szóba, ha megfelelő teljesítményt is akarok. Ill., ahogy írtad, talán még a G5 maradt a ringben.

Viszont általánosságban, nem értek egyet a megállapításaiddal. A RISC rendszerek "védelmében", amit írtam, azt az ár/teljesítmény arány figyelembe vétele NÉLKÜL tettem. Tehát, egy abszolút skálát próbáltam meg felállítani a munkaállomások között, és úgy láttam, hogy ennek a tetejére a RISC-ek kerültek. Az ettől független, hogy az áruk miatt valószínűleg csak keveseknek éri meg megvenni egy ilyen gépet.

De: a RISC-ek előnyét az x86-okkal szemben (egy bizonyos szegmensben legalábbis) én bizonyítottnak látom. Mint mondtam, nem azért mert értek hozzá. Nem értek. Viszont nagy cégekről, ahol villamosmérnökök és informatikusaok hada szolgálja ki az ilyen jellegű igényeket és végzi az eszközbeszerzést, szerintem könnyelműség azt állítani, hogy egyszerűen "megetették őket azzal, hogy HPC==RISC." Persze. Több száz (szak)embert egyszerre. Több cégnél. Egymástól függetlenül.

Szóval, mint mondtam, a technikai részletekhez nem értek. Engem az győz meg, hogy akik ezeket veszik, úgy gondolom, tudják mit csinálnak.

Ehh, erre elo ellenpelda az en munkahelyem, ahol eroteljesen az x86 vonal kerult eloterbe a korabbi sparc iranyvonallal szemben. Par tizezer geprol van szo, nehany szaz rendszermernok/ programozo egyetertesevel zajlik a folyamat, eppen azert, mert az x86 all jelenleg a legjobban ar/teljesitmeny tekinteteben.

Mondom, az ár teljesítmény arányt NEM figyelembe véve...

Egyébként pedig ahány cég, annyi feladat és annyi igény. Ezek között lehet, hogy sok hasonló van, de teljesen egyforma biztos nincs.

Ettől még nálatok lehet, hogy jobban megéri olyan gépeket venni amilyet.

Sikerult majdnem azt leirnom, amire gondoltam :( Szoval nalunk nem csak az ar/teljesitmeny miatt, hanem a nyers szamitasi teljesitmeny miatt is x86-ra allnak at, 1-2 mainframe azert megmarad batch processing feladatkorre, de a korabbi kozepkategorias szerverpark kezd eltunni. Mondjuk en az I/O miatt szivesebben latnek errefele iSeries/pSeries gepeket...

Azért az más szituáció, ha egy rendszer meg van támogatva "egy-két" mainframe-el. Egyébként ez is egy járható út. Elvileg az is megoldható lenne, hogy a júzerek csak valami minimalista munkaállomást használjanak, ha besegít hátulról egy nagyvas. (Pl.: úgy tudom az Audi nem rég épített ki linux+itanium2 clustereket ilyen célból.)

Az abszolut lista elere nem a processzor miatt fog felkerulni egy gep.

Mondom valamikor 10-15 evvel ezelott tenyleg a RISC-ek voltak a munkaallomasok, leven akkor a PC-k legfeljebb jatekra voltak jok es sok ponton alkalmatlanok voltak a CAD-FEM munkara. Lassuak voltak, keves memoriat kezeltek, nem volt rajuk jol tamogatott UNIX valtozat, nagy teljesitmenyu forditoprogramok, SMP tamogatas, gyenge volt a lebegopontos vegrehajtoegyseg hovatovabb meg TCP/IP tamogatas is csak nyomokban volt.

Akkor 10 milliardokat fektettek be a cegek RISC szoftverekbe, fejlesztesekbe, oktatasba. Most mindenki x86-64-t hasznalna, ha lehetseges lenne ezt a befektetest realizalni az uj platformon. Azaz mukodjenek a legacy szoftverek, pluginek, portolni lehessen egy csomo cuccot (mert HPC korokben elterjedten hasznalnak hazon beluli fejleszteseket). Ez nem kis gat az atallas elott. Ennek ellenere sokan szivjak a fogukat es atallnak, mert nem keveset nyernek vele (tobb teljesitmenyt kapnak a penzukert, vagy kevesebb penzbol megkapjak ugyanazt a teljesitmenyt). A szamitogepes grafikai cegek (ILM, DW, Disney) voltak az elsok, akik kidobtak az SGI ws-eket es renderer szervereket, hogy Opteronnal es Mac-el helyettesitsek oket. Nekik volt penzuk es a plugineket gyorsan elkeszitettek az uj platformra.

Aki meg nem all at, az szenved az elmaradott gepeivel (rengeteg peldat tudnek idecibalni), mert a tobb szazezer sornyi belso program tul bonyolult es mar meghalt-lelepett a fejleszto. Nem trivialis egy HPC progi korrekt portolasa. Ezeken a helyeken a legacy tamogatas a legnagyobb technologiai kihivas, mert istapolni kell a kitudjahanyeves Solarist, mert az uj verzion nem megy a regi szoft.

Te viszont a leiras alapjan uj belepo vagy, neked nem a vesztes lora kellene tenni eleve.

Nem akarok semmilyen vesztes lóra se tenni. És, mint mondtam, most, hogy itt vitatkozunk, válasszuk szét az én problémámat és a RISC vs. x86-ról szóló általános vitát. A kettő nem ugyanaz. Az elég egyértelmű, hogy abban az árkategóriában, amiben jelenleg mozogni tudok, az x86-on kívül nem nagyon jöhet más szóba.

Általánosan, én nem látom úgy, hogy azok a tapasztalataim, amik azt mutatták, hogy bizonyos cégek RISC gépeket vesznek, azért tennék, mert valamiféle kényszerpályán mozognak. Abban igazad van, hogy az x86 megoldások a legtöbb esetben költséghatékonyak. De amikor egy munkakörnyezet kialakításra kerül akkor (ezen a területen legalábbis) ez sokkal összetetteb, mint ha általános használatról lenne szó, pl. részét képezhetik különböző szerverek, mainframe-ek, stb. Én ezekre (is) gondoltam, amikor azt próbáltam igazolni, hogy szerintem miért van létjogosultsága a RISC rendszereknek. Itt már különféle együttműködési/kompatibilitási dolgokat is meg kell(en) oldani, úgy gondolom. De ez már más kérdés. x86-ban még nemnagyon láttam pl. 10-20 proc.-al szerelt "erőműveket".

Igaz, van néhány kivétel (Pl.: CRAY, NEC) de szerintem egy ilyen jellegű eszköznél jönnek elő igazán azok a hardveres különbségek, amik egy RISC javára billentik a mérleget, pl. jó adatbuszrendszer, ill. a proc.-ok közötti hatékony kommunkiáció, stb. (pl. egy "sima" clusterrel szemben, ahol ez kvázi mondjuk egy 10/100-as ethernet kapcsolatot jelent.)

No itt a pelda az atveresre. Ennek a gepnek az upgradje tovabbra is a Sun aranyarai mellett oldhato meg. Hidd el egy ev mulva keves lesz az 1 Giga RAM, 80Gb vinyo. btw ez mar most is keves. A proci sem egy versenyvarrogep. A szomszed Pistikenek meg olyan Radeonja lesz jovore 25 ropiert, hogy csuklani fog a rohogestol a te "grafikus workstationod lattan".

Ha epitesz egy korrekt pc-t magadnak olcsobban jossz ki, raadasul kis penzbol eleg sokaig tisztesseges teljesitmenyszinten tudod tartani a gepedet. Egy dual core xeon megeszi ezt a cuccot reggelire (de lehet, hogy egy ketmagos Athlon64-es is).

Grafikus témához: a CAD szoftverek régebben és most is többnyire OpenGL-t jól támogató hardvert igényelnek. Ebben kell, hogy erősek legyenek. Minden más szempontból Pistike kártyái felőlem úgy eszik meg reggelire, ahogy akarják.

Én csak azt tudom, hogy a kifejezetten CAD-re készített kártyák régen is meg tudták jeleníteni/normálisan tudták kezelni a sokezer darabos összeállítási modelleket és most is, a geforceradeonok pedig régen sem tudták és most sem. Mondjuk azért egy mittudoménmilyen "csúcs" geforce 6600 gtcxrhx... -val már lehet valamit kezdeni, de láttam már ilyet meghalni többezer alkatrészes összeállítás alatt. Szóval, CAD-re CAD kártyát. Mondjuk valamelyik quadrot vagy firegl-t. De eddig nem hallottam panaszt senkitől sem a spec. munkaállomások "egyedi" grafikus cuccairól sem. Sőt pl. az SGI-k ről néhány dícséretet is hallottam.

Na itt vered at magad....

Ha az a videokartya x haromszoget tud megtexturazni egy masodperc alatt, akkor tobbnyire tokmindegy, hogy milyen proci hasal alatta. A szoftver lelkivilagan es a programozo ugyessegen mulik, hogy mekkora modell lesz kezelheto.

A hardver egy nyers felso korlatot ad meg arra nezve, hogy mire lehetsz kepes. Hogy egy CAD szoftver milyen bonyolultsagu modellt kepes kezelni az leginkabb NEM a hardver fuggvenye, hanem magae a CAD szoftvere. Ebbol a szempontbol megbizhatsz bennem, mert vagy 6 eve ilyen szoftverek fejlesztesen dolgozom (3 ev FEM/FEA + 3 ev CAD).

Pl. az FEA algoritmusok rendes lekodolasaval (ertsd: hajlandoak voltunk az ezereves Fortran kodot atirni, modernizalni, es a legujabb algoritmusokat implementalni) kb 80-100-szorosara noveltuk az epeszuen kezelheto modell meretet.

Tehat hamar ennyire a reszletekbe megyunk, akkor az x86 is sokra lehet kepes egy Catia-val, de kevesre egy AutoCAD-del. Lehet, hogy a Axis szar szamitasokat producal neked, de a COSMOS vagy az ANSYS mar tokeleteseket (ugyanazon a vason).

Pl. lattam olyan CAD szoftvert (BoCAD), aminek a windows portja valami speci X emulatorban futott. Mondanom sem kell, hogy szarul. De ez nem az x86 vagy a windows hibaja (hacsaknem annyiban, hogy a Windows nem X kompatibilis, de ez szerintem kifejezetten elony).

ha már SGI, akkor

http://sgi.hu/modules.php?name=Content&pa=showpage&pid=28
http://www.sgi.com/products/remarketed/offering.html
VAGY INKÁBB : tezro http://www.sgi.com/products/remarketed/tezro/
vagy fuel http://www.sgi.com/products/remarketed/fuel/

ibm : http://www-03.ibm.com/servers/intellistation/pro/index.html

hp:
http://h10010.www1.hp.com/wwpc/pscmisc/vac/us/en/sm/workstations/index-…
http://h10010.www1.hp.com/wwpc/hu/hu/sm/WF04a/1090269-1111941-1111969-1…
http://h10010.www1.hp.com/wwpc/hu/hu/sm/WF04a/1090269-1111941-1277171-1…

Dell:
http://www1.euro.dell.com/content/products/compare.aspx/precn_desktops?…

apple :
http://www.apple.hu/hun/apple/hardware/macpro/

sun: http://hu.sun.com/products/munkaallomas/
http://www.sun.com/desktop/index.jsp

de ha gondolod nézz körül a NÉMET EBAY-en.

Szerintem van választék egészen a $$$ :)

Egyébként most nézegetem az Ebayt, és SGI Octane, Octane2, Fuel gépek egész tűrhető árakon vannak. A kérdés már csak az, hogy mit tudnak ezek?

Itt valamelyik hozzászólásban volt egy link konkrét eredményekről, amik alapján egy Octane nem tűnik túl meggyőzőnek. Az órajel és az, hogy 1 vagy 2 proc. van a rendszerben ezeknél a gépeknél mennyire számít? Azt hallottam, hogy ezek jobban ki tudják használni, ha pl. 2 proc. van bennük. De ez mit jelent? Közel duplája lesz a teljesítményük?

Én egészségügyben dolgozom Octane2-vel. A célszoftver új verzióját a cég portolta más platformra. Az utód egy HP workstation-on fut. Nem tudom persze, hogy ebben mennyi szerepe van az arhitecturának (MIPS vs P4 Xeon), az oprendszernek (IRIX vs Linux) és a hozzá kapcsolt célhardverekenek, de az újabb állva hagyja (és itt Palik lászló jutott eszembe) a régit.

Ugyancsak van összehasonlítási alapom Ultrasparc vs. HP workstation szinten is: ugyanaz a helyzet, mint az Octane2 esetén, csak itt még célhardver sem bonyolítja a dolgokat. Persze egy Nvidia Quadro-s HP xw8xxx sem olcsó, de az Ultrasparc-ban is van Creator3D.

Ha nem x86-ot választassz, akkor a szofverkörítés tekintetében biztosan szűkösebb lesz a mozgástered. És többet fogsz nyalókázni "egyéb" kategóriájú szoftverekkel.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( Kuvik | 2007. 01. 16., k – 10:23 )

Ha már SGI:

http://www.silicon.hu/modules.php?name=Content&pa=showpage&pid=144

Ez a OCTANE munkaállomás. Van valakinek tapasztalata vele? Lehet, hogy tudnék szerezni egyet. Tudom, nem egy mai darab, és általános használatot tekintve lehet, hogy gyenge, engem leginkább az érdekelne, hogy összemérhető-e a lebegőpontos számítási teljesítménye egy mai x86-ossal. Ezalatt azt értem, hogy mondjuk eléri-e egy mai "csúcs-x86" ilyen jellegű teljesítményének mondjuk legalább az 50-60%-át? Mert akkor (az ára miatt) elég jó lenne.

http://digitus.itk.ppke.hu/~molma/
Nem segit sokat, csak erdekessegkeppen.

Amugy az ismerosom szerint nem csak a sebesseg szamit ezeknel a munkaallomasoknal, hanem a pontossag is, tobb napi munka utan. Ebben a PC-k nagyon rosszak, hiaba gyorsak, egy ido utan elkezdenek hibazni, a SGi es Sun munkaallomasaik pedig nem. Ok SolidEdge-et es Catiat hasznalnak azt hiszem.

"...a PC-k nagyon rosszak, hiaba gyorsak, egy ido utan elkezdenek hibazni..."

hülyén fogok meghalni, de ezt nem tudom agyilag felfogni :-)

Tőlem 40 cm-re van egy mai szemmel hulladék PC (333 MHz-es Cerka), és pontosan jövő héten lesz 2 éve, hogy nem volt rebootolva... szóval mit ittál, hogy azt álmodtad, hogy hibáznak az x86-os processzorok?

--
by Mikul@s

Szerintem számítási pontosságra gondolt. Nem vagyok informatikus, nem tudom pontosan, de tényleg létezik ilyen (pl. hibahalmozás, hibaterjedés, stb.) a processzorok működésében. Ettől még működhet sokáig probléma nélkül.

(Mint a régi vicc, amikor kijött az első Pentium:
AMD: mennyi 2*2?
Pentium: 5!
AMD: nem, 4.
Pentium: jó, jó, de azért gyors voltam, ugye? :)) )

Gondolom, mivel itt minel nagyobb helyierteku kozelito ertekekkel kell szamolni, egy ido utan mar latszodhat kulonbseg a 64 es 32 bit kozott. Persze nem tudom, hogy szamolnak ezek a programok.
Peldakent olyat meselt az ismerosom, hogy beadta az adatokat, szamolt a gep ket napig, kozben hozza se lehetett szolni, aztan kiadta, hogy szerinte milyen csapagy kell ahhoz a feladathoz, csak szemmel lathato volt, hogy az keves lesz arra, amire kellene.

( turul16 v | 2007. 01. 16., k – 10:47 )

Még mindig van aki, azt hiszi, hogy egy Proci csak azért jobb, mert RISC :-D
Meg csúnya gonosz elqurt x86 ... mese. Bebizonyosodott, hogy szarbol lehet várat építeni.
(Egy procis rendszerekröl beszélek elsősorban)
------
gentóhuszár

( meditor | 2007. 01. 16., k – 11:16 )

Nekem van egy gépem, amit számolásra használok. Neurális hálók
vagy kinetikus modellek futnak rajta. Van olyan feladat ami
hetekig(!) cca. 100 %-os terhelést jelent. Semmiféle hibát
vagy elakadást nem tapasztalatam. (a procihűtő ventillátor
persze pörög mint az őrült) Kb 2 éve szinte folyamatosan
használom. A gép nem csúcskategóriás (mondjuk az
alkatrészeket jól megnéztem, mielőtt megvettem).

Proci P4, 3.2 GHz, 1024 MB RAM. Asus alaplap, Slackware 10.0
oprendszer. Az ára, ha jól emlékszem 160 kHUF körül volt 2
éve nettóban.

A grafikus teljesítmény nálam nem kérdéses, erről nem tudok
beszámolni.

Jó lenne valami teszprogram, amivel össze lehetne hasonlítani
a különböző gépek sebességét.

Ha lenne 500e forintom, valszeg egy U1 vastagságú duplaprocis
NEC-et vennék. (kis helyigény, 3 év helyszíni gari, lehet,
hogy még rá kéne dobni egy kis pénzt).

> Sol omnibus lucet.

( Kuvik | 2007. 01. 16., k – 11:14 )

Az x86 kézenfekvő kompatibilitási szempontból. ha CSAK cad-hez kellene, akkor valószínűleg azt vennék. De, mint leírtam, SZÁMOLNI is kell. (Érdekes, akárkinek/akárhol hozom fel ezt a problémát, valahogy ez a szempontot amúgy mellékkörülményként kezelik a válaszadók - általában)

A RISC-ből azért indultam ki, mert, ha erre a célra jobb helyeken ilyet használnak, az biztos nem véletlenül van. Számomra nem az a kérdés, hogy RISC-ből lehet-e jobb rendszert építeni, vagy sem, hanem az, hogy a teljesítményhez mérten költséghatékonyan hogyan tudok egy rendszert felépíteni. Ha ez x86-ot jelent, akkor x86-ot, ha RISC-et, akkor RISC-et.

Itt azért kérdezek elsősorban a RISC-ről, mivel úgy gondolom, hogy vannak itt nálam ilyen téren okosabb emberek is (lévén a RISC munkaállomások nagyrésze UNIX-os), akiknek nem csak a szomszédja hallott már olyan emberről, aki már látott képen ilyen gépet, hanem esetleg használja is, és vannak vele tapasztalatai. Az x86-okkal nagyjából mindenki képben van (vagy könnyebben utánanézhet, ha akar), mert azok elterjedtebbek.

Egyébként tisztában vagyok vele, hogy ha beszerzek egy régebbi RISC-et, az általános használatban közel sem fog olyan teljesítményt nyújtani, mint egy új x86. De, mint mondtam, engem elsősorban a lebegőpontos teljesítmény érdekel, ezért nézegetem a RISC-eket, mert állítólag ebben (is) jók. Mint már leírtam, a költséghatékonyság számít.

Nem értem miért hívják öket, RISC -nek :), van olyan hogy azon filózok hogy 1 DB RISC proci utasításnak mondot utasítást hány x86 utasításbol lehet kihozni.

Tények:
RISC -nek nevett procit tervezni általában egyszerűbb,mint jó x86 -ot. -> Kisebb fejlesztési költség, kevesebb hiba lehetőség
Kevesebb tranyóbol állhatnak -> kevesebb gyártási hiba, kisebb meghibásodási esély.

x86: Iszonyat bonyolult dolgok vannak benne, hogy elérjék azt a teljesítményt, amit nyújtanak, iszonyat nehéz olyan C fordítót irni, ami maximálisan kihasználja, a jelenlegi x86-okat.
A nagy fejlesztési kültség , rengeteg vevőn oszlik el ezért lehet olcsóbb.

Van néhány igen jól átgondolt, igen erős RISC -nek nevezett proci ,de szerintem ár/teljesítmény arányban, ha nem csúcs kategriát vesszel (1M+ felett), szerintem x86/amd64 -böl jöhetsz ki gazdaságosabban.
------
gentóhuszár

Igazibol a RISC alapelvekbol a legtobb RISC architektura csak valogat. Ugyanaz a helyzet, mint a tiszta retegszerkezettel (hasznalhatatlanul lassu), vagy a tisztan OO nyelvekkel (felesleges, eroforrasigenyes, lassu, kenylemetlen). Epp ezert a RISC gepekben is szokott lenni bonyolultabb utasitas is, amit lehet, hogy tobb x86 utasitassal lehetne csak elerni.

Amit szoktak tartani:
-azonos bitszeles minden utasitas (ez az alapvetoen CISC x86-nal nagyon nem teljesul)
-tobb regiszter van, mint CISC-en (ez mondjuk nem mindig igaz, pl. ARM)
-nagyobb cache (anno az egyik Alpha procirol olvastam, hogy a benne levo tranzisztorok 92%-a a cache-hez tartozik) - mostanaban x86-on is eleg nagy cache szokott lenni, ez a kulonbseg szerintem eltunt

A RISC-es procikat ket eleg nagy csoportba lehet osztani: az egyik a szamitasi teljesitmenyre, sebessegre tervezett csoport (Sparc, Alpha, MIPS, es tarsai), a masik a kis fogyasztasra (mikrokontrollerek, ARM). A masodik csoport most azt hiszem nem jatszik.

x86-ra szerintem konnyebb jo forditot irni, mint mondjuk egy Itaniumra, de persze izlesek es pofonok. 128 bites busz, 2x64 bit adatot, vagy 3x41+5 bit utasitast ker le egyidejuleg az Itanium. Az a +5 bit mondja meg, hogy melyik 41 bites utasitas melyik processzoregysegnek szol. Mivel egyszerre 3 ilyen kaphat utasitast, "konnyu" parhuzamositani utasitas szinten. Kar, hogy kezzel is eleg nehez ra ASM-ben programot irni, forditoprogramot meg plane.
Ehhez kepest az x86-on logikus minden utasitas, (max a regiszter allokacioval kell trukkozni), es a legtobb fordito utoleri vagy meghaladja egy atlagos ASM programozo kodjat.

A nagy piac miatt nagyon jol tudtak fejleszteni az x86-ot, jelenleg teljesitmenyben utoleri vagy meghaladja a konkurenseit (arban meg joval alattuk marad).

(Tudtommal az x86-os alapja egy RISC proci, es vagy mikroprogrammal, vagy hardware-es forditassal fut a kod, mondjuk P4 eseten. Szoval osszessegeben a RISC a nyero architektura, csak x86 CISC interface-el.)

(Az egyszeruseg kedveert x86-al jeloltem a 64 bites valtozatot is. Ma mar nyilvan nem erdemes 32 biteset venni.)
---------------------
"Monumentalis gondolataim manifesztacioi - melyek mondatok formajaban realizalodnak - limitalt mentalis kepessegeid szamara nem mind akceptabilisak. Dialogusunk kontinuitasa igy megszakad. Nem jon letre az argumentumok szintezise." - A Vektor

ja, es URISC a kiraly architektura :)
---------------------
"Monumentalis gondolataim manifesztacioi - melyek mondatok formajaban realizalodnak - limitalt mentalis kepessegeid szamara nem mind akceptabilisak. Dialogusunk kontinuitasa igy megszakad. Nem jon letre az argumentumok szintezise."

( Ice | 2007. 01. 16., k – 11:42 )

Core2Duo vagy Core2Extreme rulez ! Olcsó és finom !

( Kuvik | 2007. 01. 16., k – 12:41 )

Dual G5-ös Power MAC-ról mik a vélemények? Ha jól sejtem ezek már komolyabb darabok, és úgy láttam, használtan már elég tűrhető áron beszerezhetők. Tapasztalatok? Esetleg összehasonlító tesztek vannak ehhez?

( awexco | 2007. 01. 16., k – 13:25 )

Szia kuvik ha üzibe dobsz egy elérhetőséget akkor tudnék egy nagyon jó tudás/ árú megoldásról árajánlatot küldeni neked .

Huhh..!!! Ez komoly :) Főleg a dual Sparc-os (!) laptopok! Nem is tudtam, hogy van ilyen. Mondjuk nekem laptopban egy Powerbook 12", vagy egy Thinkpad 12" az álmom, de ez azért mellbevágó! Egy ilyen dualsparc cucc már egy komoly munkaállomás-teljesítmény és ez ráadásul laptopban! (ez már betegség :)) )

A tyanpsc-ről, meg mintha már hallottam volna, sőt, mintha egy időben az SGI-nek (?) is lett volna valami hasonló kezdeményezése, de aztán nem tudom mi lett vele. Kár, hogy ezek is az 1M+ kategória...

( meditor | 2007. 01. 16., k – 16:10 )

Továbbra is érdekel: hogyan lehet két számítógép (lebegőpontos)
számítási teljesítményét összehasonlítani? Van-e valamilyen
standard teszt program? Egyes kategóriákra mik a jellemző
értékek?

> Sol omnibus lucet.

Erre egzakt, hardvergyártók által is elfogadott módszert nem ismerek és lehet, hogy ilyen nincs is. Úgy gondoltam inkább, hogy ha van van esetleg valaki, akinek hasonló feladatai voltak/vannak, mint nekem, akkor elmondhatná a véleményét (esetleg mérésekkel is alátámasztva), hogy az ő rendszere hogyan muzsikál. A legjobb nyilván az lenne az összehasonlítás szempontjából, ha többen ugyanazokat a szoftvereket használnák mint én, és el tudnák mondani, hogy náluk hogy megy. Esetleg kiküldenék mindenkinek egy-két "iskolapéldát", és kiprópálnánk hogy mennyi idő alatt és milyen eredményt kapnak.

Persze, az sem túl nagy baj, ha nem pont ugyanazokat a szoftvereket használókkal tudnék ilyen ügyben konzultálni, ugyanis az ilyen jelegű programok hasonló elven működnek, hasonló matematikai műveleteket kell elvégezniük, ezért pl., ha valaki azt mondaná, hogy nála mondjuk az ANSYS CFD jól/rosszul működött ilyen és ilyen konfigon, akkor mondjuk valószínű, hogy mondjuk a Fluent is hasonlóan fog.

A lebegőpontos teljesítményt azért írtam, mert tudtommal az ilyen számítások elsősorban lebegőpontos értékekkel/műveletekkel történnek. Vannak egyébként erre tesztprogramok is, csak mint mondtam nem általánosan elfogadottak, amik mondjuk egy "állatorvosi ló" szerű problémát futtatnak le, mérik a futásidőt, és adnak egy számítási teljesítményértéket Flops/s-ban.

Ha van valamid, ami mondjuk egy kb 5-10 percig fut egy 2.4 GHz
P4-esen, akkor ezt lehtne tesztelésre használni. Mondjuk
millisecbe mérve a futásidőt. Szívesen kipróbálnék egy ilyet.

Lehetne ez a HUP_SPEED_STANDARD (-::

Sőt, ha sokan lefuttatnák, lehetne egy összefoglaló táblázatot
készíteni belőle tanulságként.

> Sol omnibus lucet.

Hogy van-e????? Olyan is, ami napokig fut(na)! Ha nem fagyna le közben. Sajnos, azt tapasztaltam, hogy 15-20 perc intenzív számítási futásidő felett egyre instabilabban viselkednek az átlagos PC-k. Tehát gyakran előfordul, hogy mondjuk egy feladat megoldása pl. 2 órát venne igénybe, de 5-6 lesz belőle, mert 3x kell nekiállni, mert 3 futtatásból 2x megfekszik, és csak harmadszorra fut le rendesen.

Hááát, nem hiszem. Ill. az okok változóak. Pl. volt egy VEM modellem ANSYS-ban, amit néhány kollega gépén is kipróbáltam, és ugyanolyan instabilan viselkedtek a gépek minden esetben. Töbek között ez az eset indukált nálam némi vonzódást a RISC rendszerek irányába, mert később ugyanezt kipróbálhattam egy sparc-on, és azon csont nélkül (és gyorsabban) lefutott. Persze van ami egyértelműen hardverfüggő, pl. a CATIA-GSA a számítás megkezdése előtt reklamál valami spec. intel utasításkészlet (valami Mk_xx-Libary, vagy micsoda) után, hogy úgy gyorsabban tud számolni. De már többször előfordultak ilyen gondjaim. Mondjuk, a rossz tapasztalataim egy része abból is fakadhat, hogy (kényszerűségből: másokkal való kooperálás) sok esetben windows alatt kellett ilyesmivel foglalkoznom, amikről aztán kiderült, hogy Linux alatt, wine-al(!) ugyanaz 30-40%-al is gyorsabb néha. (Persze ez nem mindig igaz)

Szerk:
Azt viszont úgy tapasztaltam, hogy ha pl. egy ilyen jellegű szoftver van win és linux alá is akkor ugyanazon a gépen, az esetek 80-90%-ában linux alatt jobban megy ugyanannak a problémának a megoldása. (mármint natív linuxos környezetben)

?!

ezt te sem gondolod komolyan, ugye?

a pc. megfekszik. szamolastol. NYIHAHAHA.

szegeny fizikusok nalunk a tanszeken, most dobhatjak ki a 200 darab pcjuket amin clusterbe szamolnak :((((

erdekes, nalunk sosem volt semmivel gond, membranszimulaciotol folyadekdinamikai szamolasokig
pedig minden fut itt...

(opteronokon foleg, 4-8-16 procisok, >=16 giga rammal. es kopkop, stabilak [najo a legujabb
16 procis opteronunk nem, de ott hw gond van, nem stabilitas])

ha gondolod, adj valami tesztprogit, amit hagyhatok futni.

van most epp spareben egy dualprocis xeonos gepem, 3g memoval, scsival.
szerintem ez mar nem a home-brew kategoria. :-)

ha ezen is behal, akkor ket dolog van: valami olyasmit csinalsz ami
x86on nagyon rossz dolog (de hogy mi lehet ilyen?), vagy rossz a program.

Konkrét tesztprogramom nincs. A konkrét példa egyébként egy ANSYS modell volt, talán még megvan valahol, ha megvan/ismered esetleg az ANSYS-t, akkor, ha sikerül megtalálnom, elküldhetem. Egyébként az én gépem elég gyatra, mint már mondtam, alapvetően ezen nem csoda, ha nem működik valami,de ezt a konkrét esetet pl. azért emeltem ki, mert ez másik gépeken sem ment normálisan. De mondjuk minden évben van 1-2 ilyesmi eset, amit nem igazán tudok megmagyarázni.
A stabilitás, az más kérdés. Én nem állítom, hogy az x86-ok ne tudnának hosszú ideig stabilan menni. Az enyém is volt már hogy ment 50-100 órákat legalább, de lehet hogy jóval többet is egyhuzamban. De ennél az esetnél a számítás miatt a processzorterhelés maximális, ami folyamatos üzem mellett, már nem tekinthető "átlagos" igénybevételnek.
De mint mondtam nem tudom mi lehetett pontosan az oka. Lehet hogy maga számítás volt olyan, ami potenciális hibalehetőséget hordozott magában. Az volt a baj, hogy akkor még jóval kevésbé láttam bele az ilyen numerikus matematikai módszerek működésébe, ma már azért igyekszem kevésbé agyatlanul használni ezeket az eszközöket, esetenként próbálok beletúrni és az igényeimhez igazítani egy ilyen programot, de ez azért még nem megy könnyen, aki ismeri az ilyesmit, az tudja, hogy iszonyat mennyiségű elméleten kell átrágnia magát az embernek (parc. diff. egyenletek, a hozzákapcsolódó stabilitáselmélet, variációszámítás, diszkretizáló algoritmusok, stb.)

x86 instabilitás úgy általában - már bocs - de hülyeség.
megfelelő hűtéssel nincs gond és pont.

ami itt a gond lehetett, az az hogy elfeledkezel róla, hogy a c forráskódból még fordítani kell, tehát a compiler nagyon nem mindegy.

például nem széles körben ismert dolog, hogy a Microsoft vc 6, vc2003, vc2005 default-ból olyan beállításokkal gyártja le az EXE-ket, hogy azok az FPU-t nem 10 byte-os, hanem csak 8byte-os double számokkal hajtják meg! Ezen egy érzékenyebb numerikus algoritmus simán elbukhat!
Egyszerűen más érték fog kijönni egyik fordítóval/procival, mint a másikkal!
(pl borland fordító ugyanazon gépen, mivel 10 byte-os long double-vel számoltatja az FPU-t, mást hoz ki, mint a Microsoft).

szóval úgy általában lebarmolni az x86-ot nem okos dolog.

" Az enyém is volt már hogy ment 50-100 órákat legalább, de lehet hogy jóval többet is egyhuzamban."

Ez nem mennyiseg... maradek alkatreszekbol osszetakolt x86 rendszer 360 nap uptime. Kozben teljesen folyamatosan 100% proci terheles /dnet kliens/. Akkor is csak egy halokartya fizikai elhalalozasa miatt kapcsoltam ki. 50-100 orat emlitesre sem meltonak neveznek... Az otthoni 1,8-as P4-is eveket ment napi 24 oraban 100% terhelessel /szinten dnet kliens/ es csak amikor ki kellett porolni akkor volt leallitva.

Udv:
Feri

Szedj le egy memtest86.bin -t, teszteld vele gépedet, ha azzal nem csinál hibát, akkor a memória és cache rendben van, és valószínüleg a proci is, ne húzd túl a procit, gyöződj meg arról, hogy nem melegszik túl.
Többször szűrtem már ki memetest-el nem megbízható ramot.

Nem instabilabb egy x86.
Nekem ez a PC volt már bakacsolva 20+ napig is, aztán véletlenül neki dölt a táskám a powergombnak, a többi esetben áram szünet volt.
Közben rengeteg C, C++ kód fordult le, ill. játszottam is (erőforrás zabáló játékkal), valamint dnetc (OGR,RSA számolgatósdi), is futott a szabad időben (vagyis mindig 100% -on, ment a prockó).
Ja és valami csoda folytán x86 szerverek is mennek éves nagyságrendeket.:)

A random fagyásokat, ezenküvül szar program okozhatja, rosz szálkezeléssel, vagy ilyesmivel.
------
gentóhuszár

és valószínüleg a proci is

Hát egyáltalán nem valószínű, tekintve, hogy memtest alatt gyakorlatilag nulla terhelése van a procinak, így könnyen előfordul, hogy ilyenkor nem hibázik, hosszan tartó nagy terhelésnél pedig igen. Persze ez nyilván hűtési vagy hardver probléma, de ettől még memtest az azért memtest, mert a memóriát teszteli, a procit ettől még nem lehet kipipálni.

Olyasmit nem lehet, hogy egy 3d-s programot ráküldesz mesa3d-vel? Tudtommal ogl elég sok lebegőpontos számítást végez. Aztán csak meg kell nézni fps-t, meg cpu load-ot meg egy két fontosabb paramétert és meg is van az eredmény. Természetesen a gép többi alkatrészének, illetve az operációs rendszernek nagyjából (vagy pontosan) egyformának kell lennie, pl. memória mennyisége...

Persze én nem tudom, ez csak egy tipp... :)

Nem tudom. Ezt a mesa3d-t már hallottam valahol, de egyébként nem ismerem. De én úgy tudom, hogy a 3D megjelenítés (legalábbis az általam használt CAD cuccoknál) OpenGL-re épül, és elsősorban a videokártyát terheli (meg a ramot is a CAD programok, de nem tudom, hogy ez mennyire függ össze a 3D megjelenítéssel)

Üdv!

Ha jól tudom, te foglalkozol MAC gépekkel. Már ugyan kérdeztem egyszer itt valahol, de nem nagyon érkezett rá válasz: Valamelyik újabb dual G5-ös (quad?) power MAC-ről van esetleg valami tapasztalatod? Láttam mindenféle teszetket, amik szerint partiban van a legújabb dualopteron/xeon rendszerekkel, van, ahol lehúzzák. Engem elsősorban a lebegőpontos számítási teljesítménye érdekelne. Erről esetleg tudsz valamit?

A legelterjedtebb lebegopontos benchmarkok:
- HPC Linpack (ez ismeros lehet, mert a top500-at ez alapjan rangsoroljak), a gauss eliminacio sebesseget meri. Anno par eve lemertem a notebookomat (IBM a31) es ha jol emlekszem 1.8GFlops korul volt. Az akkori otthoni gepem (Palomino magos 1800+-os AthlonXP) 1.5Gflops-ot produkalt. Az vele a problema, hogy hangolni kell a benchmark parametereit, amihez egy kicsit erteni kell a numerikus linalghoz. En akkor ezzel foglalkoztam, de egy mezei usernek szerintem kicsit pilotavizsgas. www.netlib.org -rol elerheto valahol.

- SPECfp ez tobbfele algoritmusbol all, amiket mindenfele HPC softwarecegektol kaptak, ok talan publikaljak is hitelesitett eredmenyeket az oldalukon. Asszem www.spec.org

( meditor | 2007. 01. 16., k – 19:36 )

Írtam egy kis progit. Lebegőpontos számolás egy nem végtelen
ciklusban. Kitettem az FTP-m re, akit érdekel leszedheti.

Nálam: ASUS alaplap, P4 3.2 GHz-n az index: 753.94 (= ennyi másodpercig fut.)

fordítás a zz scripttel, futtatás rootként, egyelőre PC alá.

- ftp használat -
domain: meditor
user: public
passwd: [enter] (=üss egy üres entert)
cd ./FLOATspeed ==> és itt a tar.gz

Jó szórakozást! (-::

> Sol omnibus lucet.

SIGSEGV
-march nélkül is
gthomas@gthomas-laptop:~/szemet/FLOAT$ uname -a
Linux gthomas-laptop 2.6.17-10-generic #2 SMP Fri Oct 13 18:45:35 UTC 2006 i686 GNU/Linux
gthomas@gthomas-laptop:~/szemet/FLOAT$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 14
model name : Genuine Intel(R) CPU T2050 @ 1.60GHz
stepping : 8
cpu MHz : 798.000
cache size : 2048 KB
physical id : 0
siblings : 1
core id : 255
cpu cores : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pni monitor est tm2 xtpr
bogomips : 3204.17

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 14
model name : Genuine Intel(R) CPU T2050 @ 1.60GHz
stepping : 8
cpu MHz : 798.000
cache size : 2048 KB
physical id : 1
siblings : 1
core id : 255
cpu cores : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pni monitor est tm2 xtpr
bogomips : 3200.41

# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 31
model name : AMD Athlon(tm) 64 Processor 3200+
stepping : 0
cpu MHz : 2375.036
cache size : 512 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow
bogomips : 4755.13
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp

A gépen egyébként naponta n órát dolgozok, miközben éjjel-nappal megy a Folding Home, és nem szoktak rejtélyes lefagyások lenni. Én nálad vmi hardverproblémára gyanakszom, tápegységprobléma, ilyesmi ...

miert is kell root jog egy benchmark futtatasahoz?
egyszeruen a time parancs nem eleg? ha eleg sokaig fut, akkor eleg pontos lesz..
szerintem kevesebb embernek van root joga egy egzotikus gephez, mint sima hozzaferese..

mas: Pongor Gyorgy, nehai egyetemi tanarnak volt egy benchmarkja.
itt erheto el, forrasban, es egy csomo eredmennyel egyutt. (Egy idoben gyujtotte ezeket.)
---------------------
"Monumentalis gondolataim manifesztacioi - melyek mondatok formajaban realizalodnak - limitalt mentalis kepessegeid szamara nem mind akceptabilisak. Dialogusunk kontinuitasa igy megszakad. Nem jon letre az argumentumok szintezise."

Kösz, tetszik az oldal. De van rajta még egyéb érdekesség is. Pl, ha egyel feljebb mentek:

http://www.hit.bme.hu/~pongor/

a lap alján.

A hivatalos állásfoglalás, khm. hogy is mondjam, kivágta az öregnél a biztosítékot, ennek emlékére pedig elhelyezte idézetként az oldalán :))))

Csipogást kiszedtem, mellette böngészek, etc P4, 3.2 GHz 713.943000
Ugyanezen a gépen pentium4-re optimalizálva: 700.464000. Őszintén szólva nagyobb különbséget reméltem :-(
(Megadtam egy [kod]-msse2 -mfpmath=sse,387[/kod]-et is.)

Érdemes egyébként a http://www.netlib.org-ról a paranoia.c-t is letölteni, és egy jót szörnyülködni.
(Itt a fenti opciókkal kaptam a legjobb eredményt.)

Asztali gepem, ezer dolog futott rajta a teszttel egyidoben.

processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 12
model name : AMD Athlon(tm) 64 Processor 3000+
stepping : 0
cpu MHz : 2000.256
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow ts fid vid ttp
bogomips : 4002.32

./float_speed

> HUP float_speed_standard.
> Hfss index: 434.218000
* DONE *

==============================================================================
Fajlszerver, kis terhelessel

processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 37
model name : AMD Opteron(tm) Processor 246
stepping : 1
cpu MHz : 1991.566
cache size : 1024 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow up pni lahf_lm
bogomips : 3987.34
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp

> HUP float_speed_standard.
> Hfss index: 328.296000
* DONE *

===============================================================================
fajlszerver I/O endurance teszt alatt (nem akartam megallitani)

HT ON
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 3
model name : Intel(R) Pentium(R) 4 CPU 2.80GHz
stepping : 4
cpu MHz : 2800.242
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc pni monit
or ds_cpl cid xtpr
bogomips : 5605.11
clflush size : 64

./float_speed

> HUP float_speed_standard.
> Hfss index: 774.473000
* DONE *

===============================================================================
webszerver 15-10Mb/s terheles mellett.

2 CPU + HT ON
processor : 3
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) CPU 3.06GHz
stepping : 9
cpu MHz : 3066.894
cache size : 512 KB
physical id : 3
siblings : 2
core id : 0
cpu cores : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
bogomips : 6134.06

./float_speed

> HUP float_speed_standard.
> Hfss index: 587.808000
* DONE *

==========================================================================

Windows XP SP2, MSVC 2005. A programból a hangokat kivettem.
Gép:


CPU típusa	Mobile Intel Pentium M 735
CPU alias	Dothan
CPU stepping	C0
CPUID CPU név	Intel(R) Pentium(R) M processor 1.70GHz
Magfeszültség	1.340 V
	
CPU sebesség	
CPU órajel	1699.97 MHz  (eredeti: 1700 MHz)
CPU szorzó	17.0x
CPU FSB	100.00 MHz  (eredeti: 100 MHz)
Memóriabusz	200.00 MHz
	
CPU gyorsítótár	
L1 kód gyorsítótár	32 KB
L1 adat gyorsítótár	32 KB
L2 gyorsítótár	2 MB  (On-Die, ATC, Full-Speed)

A memória gondolom nem lényeg, ez úgyis cacheből fut (jó esetben :))
Optimalizálás nélül,
Debug: 498.60900
Release: 3.64100 // itt valszeg a fordító kioptimalizálja a nem használt tmp_double -t
Release2: 466.469 // itt minden ugyanaz, mint a release-nél, csak a /O2 (sebességoptimalizálás) ki van kapcsolva.


#define _USE_MATH_DEFINES
#define maintitle "> HUP float_speed_standard."

#include <stdio.h>
#include <math.h>
#include <time.h>
#include <sys/timeb.h>

struct timeb 	BaseTime,NowTime;

//----------------------------------------------------------------------------------------------
//----------------------------------------------------------------------------------------------

unsigned long long AskDifUTime (void)
	{unsigned long long int	ot,tt;
	 unsigned long long int	dt;

         ftime(&NowTime);
         tt=NowTime.time*1000+NowTime.millitm;
         ot=BaseTime.time*1000+BaseTime.millitm;
         dt=tt-ot;
	 return (dt);
	}


//----------------------------------------------------------------------------------------------
int main (int argc,char *argv[])
	{double test_double,delta,run_time,tmp_double;


	 printf("\n");printf(maintitle);printf("\n");

	 delta=test_double=0.00001;ftime(&BaseTime);

	 while(test_double<10000.0)
	 {tmp_double=sqrt(test_double);
	  tmp_double=log(1+test_double);
	  tmp_double=pow(M_E,test_double);
	  tmp_double=test_double*test_double*M_PI;
	  tmp_double=sin(test_double/M_E);
	  test_double+=delta;
	 }run_time=((double)AskDifUTime())/1000.0;

	 printf("> Hfss index: ");printf("%-20f",run_time);printf("\n");
	 printf("  * DONE *\n\n");


	 return(0);
	}

Release2 bináris futtatva P4 3.0 GHz WinXP-sp2-n: 292.39
A fenti pentium M -en, csak most itt, az eredeti zz scriptel fordítva: Linux attila-laptop 2.6.17-10-generic #2 SMP Tue Dec 5 22:28:26 UTC 2006 i686 GNU/Linux. Eredmény: 527.715
És egy harmadik gépen, szintén eredeti: 734.162000
Linux 2.6.15-27-686 #1 SMP PREEMPT Fri Dec 8 18:00:07 UTC 2006 i686
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping : 1
cpu MHz : 2999.366
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni monitor ds_cpl cid xtpr
bogomips : 6003.50

Ez egy HT-s proci, van cpu1 is, csak azt nem másoltam be.

Hogy van az, hogy linux alatt lassabb? Ez az utolsó érthető, mert SMP-s kernel, és csak az egyik cpu-n futott. De ha ezt leosztom /2-vel, akkor is lasabb.

Hol lehetne húzni a gcc-s fordítón, hogy jobb legyen a fordított kód?

Lefuttattam én is a tesztet. Egyszer az előre fordított binárissal, egyszer meg saját fordítással. Érdekes az eredmény: 


[root@localhost FLOAT]# ./float_speed

> HUP float_speed_standard.
> Hfss index: 564.707000
  * DONE *

[root@localhost FLOAT]# ./zz
cc  -march=i486 -O2 -fPIC -Wall float_speed.o -L/usr/X11R6/lib -lm  -o float_speed
[root@localhost FLOAT]# ./float_speed

> HUP float_speed_standard.
> Hfss index: 482.068000
  * DONE *

[root@localhost FLOAT]# cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 8
model name      : AMD Athlon(tm) XP 1800+
stepping        : 1
cpu MHz         : 1528.985
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up ts
bogomips        : 3059.77

A tesztek közben semmi nem futott mögötte, ami sok cpu használatot generálna. Alap kde egyetlen konsole ablakkal fc6-on.

bm-ansi benchmark: 



===== Results of bench marks V.6.4,  Pongor, György =====

Type of machine : AMD Athlon XP 1800+, 1528.985 MHz, 256KB

Type of compiler : gcc 4.1.1, command: gcc -o bm-ansi -lm bm-ansi.c

Name of this result file : bm-ansi.txt

 Length of integer = 32 bits 
 Length of double mantissa = 53 bits
 Length of address = 32 bits 

 Precision of time estimation = 1%
 Clock resolution = 1000000.000 clocks/sec
 ==> Minimal execution time of one test:     2 sec

 Test 1:  Direct select. sort 1000 real numbers   ----- Time=    0.00512 sec
 Test 2:  Discrete Fourier Transform of 128 reals ----- Time=    0.00308 sec
 Test 3:  Find first 1000 primes                  ----- Time=     0.0185 sec
 Test 4:  Sieve of Eratosthenes with 2000 numbers ----- Time=   6.11e-05 sec
 Test 5:  FFT of 1024 complex numbers             ----- Time=   0.000294 sec
 Test 6:  Invert a matrix of 50 * 50 reals        ----- Time=    0.00344 sec
 Test 7:  Calculate Binom(18,7)                   ----- Time=   0.000725 sec

 Average performance :  1282.2  "MicroVAX II MIPS"



----- Summary of results -----
 Machine : AMD Athlon XP 1800+, 1528.985 MHz, 256KB
 Compiler : gcc 4.1.1, command: gcc -o bm-ansi -lm bm-ansi.c
|fpp? |   32     53    32 ? |    5.117e-03    3.076e-03    1.852e-02    6.113e-05    2.942e-04    3.437e-03    7.246e-04  |   1282.209  |

Ez: "MicroVAX II MIPS" mit jelent? Ez a proci hozott hasonló eredményt? Vagy mit? :)

Ja! Még az jutott eszembe, hogy nem lenne célszerűbb egy olyan program is, ami nemcsak a sebességet, hanem a pontosságot is összeveti? Persze kérdés, hogy mi az etalon pontosság. Nem tud valaki mutatni mondjuk algoritmust a PI számolásához, ahol kaotikus jelenségek felléphetnek? Mert itt legalább lenne etalon. Vagy lorentz-attraktort számolhatnánk emulált 128+ bites pontossággal, az lehetne egy etalon, a többi meg mehet sima double-vel. Valaki? (ez most olyan kérdés, ahol én lusta vagyok megírni, de érdekel, és azt várom, hogy elvégezze helyettem valaki más, aki kevésbé lusta :))

( bitumen | 2007. 01. 16., k – 22:06 )

525 ezen a procin:
(ondemand governor)

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Pentium(R) M processor 1.80GHz
stepping : 6
cpu MHz : 600.000
cache size : 2048 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe est tm2
bogomips : 1199.53

( gabrielakos v | 2007. 01. 16., k – 22:19 )

"A CAD-es munkaállomások (és szoftverek) csúcsát (a "közhiedelemmel" ellentétben) jelenleg a különböző RISC + UNIX/Linux rendszerk képviselik"

Hardveresen (majdnem) biztosan nem. Abban a kategóriában pláne nem, amit megjelöltél.
Szoftveresen elképzelhető olyan dolog, ami még nincs meg linux/x86 -ra.

Szerintem a legjobban egy core2duo configgal jársz (perpillanat), esetleg SMP be téve mindjárt. Plusz egy(két) durva videókártya. Mondjuk ez már túllépi az 500k-t valószínűleg. Meg én vennék alá rendes I/O-t, azaz több SATA2 diszket, raid10-be téve.

Szerintem...

--
Gabriel Akos

Hááát nem tudom... Abban a kategóriában amit megjelöltem, úgy néz ki nem. Egyébiránt pedig nézd meg mondjuk ezeket:

http://www-03.ibm.com/servers/intellistation/power/285/index.html
http://www.sun.com/desktop/workstation/ultra45/
http://h10010.www1.hp.com/wwpc/us/en/sm/WF05a/12454-296719-296721-30790…

De ezek csak 1-2 processzoros asztali rendszerek. Én a RISC előnyét inkább abban látom, hogy léteznek 4, 8, ... vagy mondjuk akár 50 processzorral is "mainframe" gépek CAD/CAE célra. Nos, ilyet x86-ban még nem nagyon láttam. Ráadásul ez a terület eléggé speciális. Lehet, hogy ezek a gépek általános használatban nem teljesítenének jól, pl. senki ne akarjon velük játszani, ezért is szajkózom itt a lebegőpontos számítási képességeket, mert úgy tudom, hogy ezen a területen ez számít nagyobb súllyal.

Egyébiránt nem vagyok informatikus, ezért aztán nem látok bele annak a részleteibe, hogy ilyen célra, akik megengedhetik maguknak miért vesznek mégis ilyen gépet. Nem értek pl. egy proc felépítéséhez olyan mélységben, ami ahhoz kellene, hogy ránézésre megmondjam egy architektúráról, hogy az milyen feladatokban fog jól teljesíteni, és milyenekben nem. Vannak általános ismereteim, amiket az iskolában tanultam, de semmi több.

Mindenesetre az tény, hogy az ismeretségi körömben az olyan cégek/munkavállalók, akik a CAE feladatok "krémjét" végzik, törekednek arra, hogy ilyen rendszereket használjanak. És többnyire úgylátom, hogy meg vannak elégedve velük. Többek között egy ismeretség kapcsán volt már alkalmam kipróbálni egy-egy alkalommal egy sparc ill. egy power alapú munkaállomást, ahová vihettem a saját munkáimat is egy "próbakör" erejéig. Azt kell mondjam, hogy meggyőzően viselkedtek. Szubjektív és objektív (időmérés) szempontból is.

Egyébként ez az egész a "megfelelő eszközt a megfelelő helyre" dologról szól. Lehet, hogy egy zsír új dualopteron/xeon csoda bizonyos tekintetben jobban is teljesíthet egy hasonló kaliberű RISC munkaállomásnál. Ezt nem tudom. És, mint mondtam nem látok bele a részletekbe. Azonban, hogy mennyire felel meg egy adott gép egy adott feladatnak, az azért nem csak a proc.-tól függ. Én inkább azt csodálom ezekben a RISC gépekben, hogy minden elemüket tekintve erősek, rendszerként működnek jól. Talán ezért (is) váltak be az ilyen jellegű területeken. Legalábbis én így látom.

"Mindenesetre az tény, hogy az ismeretségi körömben az olyan cégek/munkavállalók, akik a CAE feladatok "krémjét" végzik, törekednek arra, hogy ilyen rendszereket használjanak"

Konfiguráltam már ilyen munkaállomást egy ügyfelemnek, aki ilyen "krém" CAE munkákat csinált.
Már nem emlékszem a pontos tipusra, viszont UltraSparc IIIproci volt benne, 8GB RAM, és egy brutál vidoeokártya, ami akkori listaáron kb 700K volt. Az egész vas kb 2M körüli árban futott (1-1.5 éve).
Azért választotta ezt a gépet a srác, mert akkor még a Win nem tudott ilyen mennyiségű memóriát kezelni (kipróbálta, nem ment), és a szoftvere win mellett csak Solarison futott.

Szóval high-end munkaállomás kategóriában szerintem is nagyon jó választás a RISC alap, viszont ennek teljesítmény/ár aránya rosszabb egy x86/x64 architektúrájú vasnak.

"Én inkább azt csodálom ezekben a RISC gépekben, hogy minden elemüket tekintve erősek, rendszerként működnek jól"
Ezt én is így látom. Ez főleg RISC szervereknél látszik igen jól.
Viszont, ha ugyanakkora összegből veszel egy új x64 alapú vasat, a 2-3 éves RISC helyett, akkor az új, elemenként erősebb rendszered végeredményt tekintve jobban teljesíthet, mint a régebbi, de "rendszerként optimálisabban" működő vas.

Egyébként meg a "feeling" is sokat számít - és szerintem te ez alapján fogsz RISC-es vasat venni végülis. :) :) :)

jó pár éve láttam egy SUN grafikus kártyát 30e dolcsiért
volt benne 1G ram, +144M framebuffer memória a kártya kb 5 kiló volt,
valamint áramfelvétele is hatalmas, de gondolom nem quake-hez tervezték
hanem CAD/CAE rendeszerekhez ahol pl egy repülő rajza nem két vonalból áll.

és akkor volt benne 1G ram mikor a pc-s grafikus karit 128m nál jártak kb.
viszont az ára is ott volt, persze megemlítették hogy a profi munkához 2-t ajánlanak a sun munkaállomásba

Celeron-M 1400Mhz, 768M, Debian SID, 2.6.18-rc7

Hát igen. 5kg már önmagában is a nyers erőt képviseli egy grafikus karinál... :)

Egyébként most jut eszembe, nekünk suliban szokott lenni műszaki ábrázolás óra, mostanában solid edge-t használunk winxp-n vmilyen ati karival. Elképzelem, mennyire megfeküdnének azok a gépek egy komolyabb munkától. Amúgy is szerintem solid edge nem éppen a tervezőszoftverek királya... (Azért érdekelne, mennyire veszik komolyan ezt a progit, akiknek ez a munkájuk.)

khm... SolidEdge... Hogy is mondjam... Tökéletes program... amíg nem akarsz mondjuk egy faéknél bonyolultabb dolgot tervezni vele.

Nekem nagyon rossz tapasztalataim voltak vele. Butított parasolid kernel van benne (hogy ne csináljon házon belül konkurrenciát az NX-nek), a butítás pedig nagyon jól sikerült. Teljesen normális használat mellett is rengeteg geometriai hibát produkál, ha pedig bonyolultabb dolgokról van szó, (pl.: speciális áthatások, nem-analitikus felületek) akkor végképp megfekszik. A rajzkészítésről meg inkább nem mondok semmit. Ha lehet az még rosszabb mint a testmodellező rész.

Ja, igen a "feeling". Az tényleg megfogot, de gondolom ez már úgyis látszik rajtam. :) Viszont annyira nem állok jól, hogy hagyjam, hogy az érzelmeim vezéreljenek. Nem játékot akarok venni, hanem munkaeszközt, amire van egy rögzített keretem. Ez a jelenlegi körülmények között erősen úgy néz ki, hogy most valami x86 lesz (esetleg G5).

A "feeling" legfelejebb csak abban fog megnyilvánulni, hogy mondjuk később veszek mellé egy öregebb (olcsó) RISC-et, játszani.

De ez semmin sem változtat.

Ezt ugy vaktaban talaltam:
http://h10010.www1.hp.com/wwpc/us/en/sm/WF05a/12454-296719-296721-30790…

Nem tudom mennyire gyors igazabol, de valoszinuleg sima CPU/memoria sebessegben vetekszik az altalad megjelolt munkaallomasokkal.
A grafikus kartya ellatottsag szinten jo ma mar PCken. Ami erdekes lehet, hogy az OSen ami ezen elfut elfut-e a szoftver amit akarsz.

Ugyan nem FPU hanem javaresz INT szamitasokban, de mar 4 evvel ezelott randan elporoltak a Proliant DL380-ak a HP 9000/L2000 (RP 5470), vagy az akkor eppen uj Sun Fire 280R gepeket. (emlekezetbol irtam a tipusokat, szoval 80%ot adok a pontossagnak :)).

Akkor jo neked a RISC ha nagyon nagy single system image rendszert akarsz tekerni.
pl 20 proci meg 200G memoria.

Egyebkent manapsag nem sok teteje van. Meg a szoftverek elerhetosege szorithat sarokba.

( _ventura_ v | 2007. 01. 16., k – 23:39 )

nyahh meditor benchmarkjanak eredményei:
743 sec egy 1400MHz Celeron-M proci debian 4.1 gcc
237 sec egy 2.2GHz es opteronon SUSE 4.1 gcc
163 sec egy 1.4GHz Itanium 2 suse 4.1 gcc

Celeron-M 1400Mhz, 768M, Debian SID, 2.6.18-rc7

( meditor | 2007. 01. 17., sze – 06:46 )

Sziasztok!

Látom elég sokan letöltöttétek a progit. A root a csipogás
miatt kell (ioperm), nyugodtan ki lehet szedni. Érdekes
a P4-esek gyenge eredménye. Sajnos lehet hogy a lebegőpontos
számolás sebbességét zavarja a ciklusok nagy száma, ezt
javítani fogom.

Teszek bele egy kis ram_speed tesztet is meg egy egyszerű
utasítás_végrehajtás_tesztet is, illetve javítani fogom a
kimenetet is: írja fájlba az eredményt és csapja hozzá
a cpu infót.

Csak este tudok vele foglalkozni, remélem holnapra kész lesz.
Lehet, hogy nyitok neki egy külön topikot.

Üdv mindenkinek: meditor

> Sol omnibus lucet.

( dii | 2007. 01. 17., sze – 10:27 )

Hi!

Ha mégis x86 mellett döntesz, tudok egy olcsó nVidia Quadro Fx kártyát. (Ezek azok amik direkt CAD-hez megy egyéb tervezéshez vannak tenyésztve.) A helyzet az, hogy sima munkaállomásba vettek véletlenül ilyet a cégnél, és ha kicserélem valami akármilyen kártyára, az is tök jó lesz oda. Egy Quadro FX 1400-ról van szó, adatok itt:
http://www.nvidia.com/page/qfx_mr.html
Olyan 600$ körül mozog az ára, fél áron megoldhatjuk, számlával is. Írj ide, azt küldök mailt a részletekről, ha érdekel.

( Kuvik | 2007. 01. 17., sze – 16:13 )

Van egy ötletem itt a nagy benchmarkolás, meg kialakulófélben lévő RISC vs x86 flame war közben. egy kicsit talán tisztábban lehetne látni általa, meg segítene megoldani a problémámat is, amiért a fórumot nyitotta. A következőről lenne szó:

Ha jól emlékszem, néhány évvel ezelőtt a müncheni TU-n valamelyik agyas írt egy egész korrekt kis VEM programot. Nem túl nagy és GPL (csak hogy a különböző aggályoknak elébe menjek :)) Arra gondoltam, hogy csinálok ehhez egy "orvosi ló" szerű VEM-problémát, pl. szilárdsági analízis, valami összetettebb geometriára (mindenképpen testmodell), mondjuk Mooney-Rivlin anyagmodellel, nem struktúrált, változó sűrűségű hálófelépítéssel, vagy valami hasonlót. A lényeg, hogy eléggé összetett legyen. A modellt szétküldöm a vállalkozó kedvűeknek, szépen mindenki lefuttatja, és megnézi, hogy ez mennyi időbe tellett (valószínűleg fel lesz tüntetve az eredményfájlban, úgyhogy külön mérni legfeljebb csak ellenőrzésképpen kell.)

Ez elhetne egy újabb mérőszám, és nekem is segítene.

Azt nem ígérem, hogy ezt hamar összehozom, mert még meg kell keresnem ezt a programot, és utána kiagyalni még egy megfelelő modellt is. Remélem, mondjuk holnapig sikerül.

( _ventura_ v | 2007. 01. 17., sze – 16:51 )

ahogy látom meditor benchmarkja eddig az 1.4 GHz es Itanium 2 esen
teljesített a legjobban.

Celeron-M 1400Mhz, 768M, Debian SID, 2.6.18-rc7

( emberk | 2007. 01. 17., sze – 19:53 )

Szerintem inkább rakj össze magadnak egy multiprocis gépet (az alaplap ami több procis nem sokkal drágább mint az egy procis). Árban tuti jobban jársz. ha a pénz nem számít akkor ppc A mac gyárt olyan gépeket hogy az ember füle és a pénztárcája ketté áll tőle. Sőt a del cég megrendelésre is gyárt hardvert hasonló (anyagi)hatással mint a mac. De szerintem a legjobb módszer az építés mert tudod hogy mit raktál bele, csak jó alkatrészeket vagyél.

( meditor | 2007. 01. 17., sze – 20:02 )

Megírtam azokat a dolgokat, amiket jeleztem előre. Tehát:

1. lebegőpontos teszt
2. memoria használat teszt
3. ciklus és vezérlésátadás teszt.

Nyitok neki egy topikot.

> Sol omnibus lucet.

( rpsoft v | 2007. 01. 17., sze – 23:47 )

Hamár a lebegőpontos teljesítménynél tartunk: én (fizikusként) gyakran számolok peremértékprobléma-megoldásokat számítógéppel. És néha jó lenne az x86 double-jénél nagyobb pontosság (long double).
Tudtok olyan vasakat, amik ezt hardware-ből tudják (nem kell nagyon gyorsnak lennie, kb. mint egy közepes p4 double-vel).

( Kuvik | 2007. 01. 18., cs – 14:04 )

Találtam két (kompromisszumos) ajánlatot:

https://eshop.worldinternet.hu/?p=productsList&iCategory=16

Ezekről mi a véleményetek?

Ez milyen árnak számít? (+ÁFA)

Szerk.:
Még, annyit, hogy az IBM, ugyan olcsóbb valamivel, de kell bele egy videokártyát, mert alapból szervernek van kiépítve. Egyáltalán bele lehet tenni? (PCI-express elvileg van benne)

Hello Mindenki!
Olvasgatom a fórumot, mosolygok, hogy milyen segítők vagyunk ismeretlenül.

Én több mint 10 éve Pro/Engineerrel dolgozom és eléggé elhivatotnak érzem magam ezzela CAD-del.Jelenleg fejlesztőmérnökként használok Renderinget, NC Maróprogramokat írok és ritkán de néha a munkámhoz szükségem van végeselemanalízisre is. A saját és vállalati gépek összeállításába segítkezve fontos számomra hogy a ProE-nak megfeleljenek a vasak. Ezért elég sok pc-t tesztelgettem már proE-val.Mindig vizsgálgatom különböző teszterekkel, a céges és magán gépeket is. A munkám során is sok memória hibás géppel találkoztam amely itt-ott hibát vétet kicseréltük két egyforma modulra és huss mint aki redbult ivott a gép feléledt és azóta is hibátlanul fut.

Tehát a tapasztalatom az, hogy nem csak a proci, az alaplap vagy az oprendszer a lényeg. Csúcs gépek is képesek rosszabb eredményt adni, mint egy silányabb noném.

Legutóljára egy Sun Ultra 20 Opteron 64bit NVIDIA Quadro 4G RAM-os gépet sikerült tesztelnem.(Ami eddig álmaim netovábja volt.) kb 600 000Ft.
Egy átlagos kis "CAD munkagép" P4,1GB RAM Nvidia stb. munkáját(NC program,rendering végesanalízis) tizedannyi idő alatt végezte el. (Megjegyzem nagyon zajosan)

Másik példa: a Munkahelyi noném P4 3GHz 1.5GB RAM Nvidia Quadro lassabban végzi el a munkákan, mint a saját cégem válogatott "vasakból" P4 1.8GHz 700MB Nvidia Geaforce.(kb 1.2x lassabb)

Harmadik példa: G5 aranyos kis masina, csendes kis erőgép, ha a szoftvereidet megfelelően illeszteni tudod rá, én ajánlom. Sajnos mi a sajátunkat elpukasztottuk úgyhogy sokáig nem tesztelhettük. Egyébként tudjátok, hogy a G5-ben vízhűtés van, és a szivattyút mi fejlesztettük magyarországon? (legyünk büszkék :-) )

Negyedik példa: egy vacak régi gépen, 5 éves P4-es 1.8Ghz a windows mellé feltelelpítettünk linux-ot és hát nagy "csodálkozásomra" a linux alat min. 10%-kal jobban futott a ProE mint a win-en. Elgondolkoztató. Sajnos még Solárisos ProE-t még nem sikerült kipróbálni, viszont elmondások alapján ott is sokkal stabilabb és gyorsabb. Tehát egy AM2-es Silent SUN Opteronnal Solaris-szal is ütős lehet, vagy REdhat esetleg SUSE stb.

Végezetül a fíling, ahogy írsz olyan mint amikor a windows után megismerkedsz egy linux-al.
Szóval én azt ajánlom neked egy szakértővel válogas össze vasat és ne csak a tipusát nézd meg, hanem lehetőleg a gyártója is egyezzen meg (pl. Asus alaplap asus video kártya.)
Ahogy valaki már ajánlotta neked: duál proci nagy memoria gyors wincseszter esetleg RAID és egy közepes videokártya. Sajnos az Ansys-t nem ismerem, de minden szoftverhez ajánlanak hardvert, ezt megvizsgálva és a lehetőségeidet felmérve találni fogsz ennyi pénzért.

Majd ha ez megvan akkor az általad használt Ansys-t ted fel egy legstabilabbnak tapasztalt oprendszerrel. Egy jól konfigurált Linux :-)

Ja a vas vásárláshoz: ha ilyen sok pénzt költesz egy gépre, nagyon sokat is tudsz alkudni egy új gépnél, ezzel szemben egy régi majdhogynem fix áras. Én mint egy "rossz" vásárló a legutóbbi munkaállomásom vételekor a már kapot árajánlatokkal házaltam és érdekes mód tudtam még harmadjára is alkudni az árból (hivatalos helyen számlára). Persze olyan is volt aki elzárkózott, de természetesen ő csak alkalmazott volt.

Utolsó és abbahagyom
PII-est 128MB NVIDIA Geforce 2db egyforma 20GB IDE Wincsi-t linux alatt RAID-be rendeztem és lás csodát hiper kis gép lett belőle. Ekkorát semmivel nem tudtam rajta javítani.

bocsi, hogy általánosságból írtam, de konkrétan neked kell kiválasztani az elemeket és nem "egy" PC-t vagy "egy" Risc-et fogsz venni.
Üdv
Gombosur