Aktív témák
-
basiC
tag
Üdv!
A kérdésem a következő:
CAD feldolgozással és látványkép rendereléssel foglalkozom /a játékon kívül :)/, és új konfigot szeretnék összeállítani. Win2000 1-2 procis változata van fent oprendszernek.
AMD vonalon nyomultam eddig, ezt lehetőség szerint szeretném is megtartani. Mit javasoltok? Legyen inkább egy duál procis gépem a régebbi XP /2400+ pl/ közül vagy ruházzak be az új fejlesztésekbe /Barton/? Még kérdés, hogy milyen sebességű ramot tegyek bele... a többi hardwer azt hsizem, hogy tiszta.
Köszi!
basiCba$iC
-
beckt
csendes tag
Szerintem mindenképpen amd vonalon maradj dualban, mert egyrész intel vonalat nem lehet megfizetni, másrész CAD-hez és renderhez is FPU kell...
Amit javasolni tudok:
-ASUS A7M266-D+LAN - 50,9e + áfa
-MSI K7D Master-L 49,9e + áfa
Sajnos a többi dual amd lap elérhetőségéről egyszerűen semmi infóm, remélem majd a kollegák bemondják...
Procinak szerintem a legkifizetődőbb két db XP 2400+ - 2x25,2e + áfa
Ugye tudod, hogy kicsit gányolni kell vele, hogy menjen duálba?
Ramból pedig te tod mennyi kell... Ha 24 órás a gép, szerintem megéri az ECC azt a rohadt sok pénzt, ha nem, akkor inkább 1-3 naponta restart oszt kész...
Remélem kiindulásnak jó lesz ;-) -
beckt
csendes tag
Tényleg tud valaki valamit a fenti lapok barton támogatásáról?
-
Sesy
aktív tag
Helló!
Ezen a témán én is elég sokat gondolkodtam már... :))
Tényleg fontos kérdés, hogy milyen programot használsz, hogy ki használja-e a több processzort!
A 3dMAX kihasználja de a többi?
Kérdés, hogy olyan programnál ami nem használja ki a több procit, amíg renderel a géped akarsz-e mellette játszani, ha igen dual, ha nem akkor minek...Born stupid... Try again!
-
marcee
addikt
Előre szólok, hogy általában azt szoktuk kihozni az ilyen topicocban, hogy egy db csúcsprocis géppel jobban jár a kedves józer.
Top multi proci megfizethetetlen, 2db lassabbnál meg jobban jársz egy gyorssal, kivéve ha nagyon jó optimalizált a progi, teszem aszt ha éjjel nappal renderelnél rajta, akkor a két proci nyerőbb, de szerkesztéshez modellezéshez nem. A teljesítménynövekedés alkalmazástól függően 30-80%. Viszont az alaplap nagyon drága.\m/
-
mzperx
aktív tag
Még egyszer megkérdezem... milyen szoftverhez? Ugyanis mondhatunk akármilyen lapot, de ha a szoftver nem használja ki, akkor mit ér vele a kérdező?
Én csak az ajtót mutatom meg, belépni Neked kell rajta...
-
beckt
csendes tag
Ízlés dolga, hogy az ember render mellett mit csinál. Mondjuk játszani én sem szoktam, de modellezek tovább vagy ilyesmi és nem mindegy, hogy milyen a rendszer reakcióideje közben... De mondjuk az egész rendszer más érzés... Nem feltétlenül a sebességérzet ami más egy egyprocis géphez viszonyítva, hanem a terhelhetőség... Mondjuk a TV-n megy egy divx-es film közben, mp3 tömörítés, cd írás egyszerre... Nem mintha ezek akkora nagy feladatok lennének, hogy egy egyprocis gép nem vinné el őket egyszerre, csak nem mindegy ezek közben még mindig lehet dolgozni, pl még mindig simán modellezek közben...
-
beckt
csendes tag
Mégegy nagyon fontos dolgot érdemes megemlíteni - bár cadhez nem tudom mennyire jön majd jól - az a divx tömörítés. Ha megvan egy látványterv és mondjuk videot renderelsz belőle (pl egy kőrút az épületben vagy ilyesmi) az sem mindegy, hogy utána a lerenderelt videoból mennyi idő alatt lesz divx... Itt pl iszonyatosan kijön a power... De mp3 tömöríteni is lehet duálban, ha pedig nem találsz olyan progit amit támogatja, elindítasz kettőt belőle és taskmanaggerben szépen beállítod az affinitást...
-
Nekem lenne egy nem teljesen ide kapcsolódó, de értelmes kérdésem
Mi kell ahhoz, hogy profitálhassunk több processzorból?
1,Elegendő egy megfelelő operációs rendszer, pl linux vagy bármiylen nt alapú win,
és akkor a task1 fut az 1. procin, és a task2 fut a 2. procin, és igy a két task
valóban párhuzamosan fut?
2, Vagypedig task1, és task2 is olyan algoritmusokat használ, amelyek profitálnak a több processzorból (pl párhuzamos rendező algoritmus). És ezek a taskok több szálon futnak (közös memóriaterület) és az egyes szálak külön külön versenghetnek a processzorokert, tehátelőfordulhat, hogy task1 nek az első szála
az 1. procin fut a 2. pedig a 2. procin, task2 szálai meg várják, hogy ütemezve legyenek...
remélem értitek a kérdést, azért kérdezem, mert órán nem értettem meg tökéletesen...
Elsősorban konstruktív hozzászollásokat várok (értsd házigazdák, kovács úr, localhost) -
basiC
tag
ArchiCAD ot használok és Artlantist, ezek egyelőre asszem nem használják ki a duál procit, ahol inkább ennek az előnyét látom, hogy a 2 alkalmazás egyszerre futhatna, és nem venné el a prociidőt az 1ik a másik elől...
Buherálni meg nem akarok, mert alapszintű hardweres ismereteken túl nem jutottam...
anyagiak: alaplapra nem sajnálom a pénzt ha jó, de ezek a 100 E Ft os Bartonok szerintem irreálisak.ba$iC
-
-
basiC
tag
Mármint tudom, hogy a Barton nem alaplap, értsétek jól :) a 2400 + os procikon mit kéne buherálni amúgy, hogy menjenek duálban?
ba$iC
-
beckt
csendes tag
Hivalatosan csak az MP-k mennek dualban. Sajnos minden mást (XP) grafitozni kell, úgy ahogy a szorzólockhoz... keress rá a fórumban, már volt róla szó... Ha erre nem vállalkozol, akkor viszont nagyon elszáll a dolog árban. Az Athlon MP procik nagyon-nagyon drágák és fizikailag semmiben nem különböznek az XP-ktől... Többet vannak gyárilag tesztelve meg ilyensmik...
Más: Kétprocis rendszerben két dolog futhat egymástól függetlenük külön procin (persze itt a memóriahasználattal vigyázni kell, mert a lassú ram, alááshatja a rendszert), meg futhat úgy is, hogy a szálak össze vissza vannak a procikon. Ha viszont egyetlen alkalmazást akarsz futtatni egyszerre (pl valami render sw), akkor nagyon kell rá figyelni, hogy több szálon rendereljen és azt hatékonyan tegye... -
beckt
csendes tag
A szorzólock szorzóunlock akart volna lenni...
-
basiC
tag
Végül is most néztem, hogy az MP proci is kijön 50E/Db-ból... de eddig inkább az a benyomásom, hogy win alatt ilyen hagyományos alkalmazásokban nem igazán kifizetődő a többprocis dolog... illetve rossz az ár/teljesítmény aránya az 1 procis cucchoz képest... szerintem...
ba$iC
-
-
-
marso
tag
az mondjuk mellekes szempont hogy a cad programok lenyegesen jobban mennek p4 en mint amdn :D de talan olcsobb egy 1-2 gepes renderfarmot osszerakni mint egy meregdraga mp alaplap + huzos aru mp-processzor
-
basiC
tag
Igen... meg most hogy olvastam az anandtech-en a dual procis gepekrol, és kiszámoltam mibe kerülne ha tényleg MP procikat + alaplapot használnék /+ high en videokártya/, egész olcsónak tűnik ez a 3000+ os Barton :).
Az Intel - AMD viszony a CAD programoknál, nos erről nincs infóm, de már írtam mailt 1 fószernak, aki a Graphisoftnál fejleszti az ArchiCADet, talán ő tud többet mondani a témában.ba$iC
-
Pötyi
őstag
Utoljára Santa Cruz unix alatt láttam olyat, hogy ''BINDING PROCESSES TO PROCESSORS'', vagyis konkrét programokat lehetett többprocesszoros gépen operenciás rendszer szinten az egyik, meg a másik procihoz rendelni, szoval volt ilyen állítási lehetőség...
4.0-ás NT és 2k alatt mintha nem találkoztam volna ilyesmivel... :DQNX is cool!
-
Pötyi
őstag
Az a PRIORITY! :D
De az csupán azt állitja, hogy mennyi gépidőt kapjon a paripa...
Tulajdonképpen kétprocis gépen ezt még nem próbáltam... Lehet, hogy többprocis környezetben más menűpontok lesznek?
Egyprocis gépen csak olyat látni, hogy:
Realtime
High
Normal
LowQNX is cool!
-
marcee
addikt
A animáció renderelésének és abból n-pass divx kodolásnak teljesítményigényét nem nagyon lehet összehasonlítani.
(Pár napja készítettem egy 250 képkockás loop animot egy általam tervezett épületről, ArchiCad -> Art*Lantis -> VirtualDubMod+DivX5. Hát kb. 55perc az 4 perccel szemben volt az arány, úgy hogy nem voltak durvák a renderbeállítások és az art*lantis még gyors is)\m/
-
basiC
tag
elvileg itt van még 1 változat a témára, most hallottam 1 hozzáértőtől: Intel, HT proci... kicsit várni, míg lemegy az ára + várni 1 kicsit, hogy mi újság lesz RAM fronton... kész szerencse, hogy nem holnap akartam boltba menni :)
ba$iC
-
Nekem lenne egy nem teljesen ide kapcsolódó, de értelmes kérdésem
Mi kell ahhoz, hogy profitálhassunk több processzorból?
1,Elegendő egy megfelelő operációs rendszer, pl linux vagy bármiylen nt alapú win,
és akkor a task1 fut az 1. procin, és a task2 fut a 2. procin, és igy a két task
valóban párhuzamosan fut?
2, Vagypedig task1, és task2 is olyan algoritmusokat használ, amelyek profitálnak a több processzorból (pl párhuzamos rendező algoritmus). És ezek a taskok több szálon futnak (közös memóriaterület) és az egyes szálak külön külön versenghetnek a processzorokert, tehátelőfordulhat, hogy task1 nek az első szála
az 1. procin fut a 2. pedig a 2. procin, task2 szálai meg várják, hogy ütemezve legyenek...
remélem értitek a kérdést, azért kérdezem, mert órán nem értettem meg tökéletesen...
Elsősorban konstruktív hozzászollásokat várok (értsd házigazdák, kovács úr, localhost) -
neduddki
nagyúr
HI!
Elnezest de nem nagyon volt idom atolvasni! Ami biztos, hogy mindenkepp tudd emg, hogy a tobbszalusagt tamogassa-e a cad progi!
A Archicad, catia, ideas, unigraphix, biztos ,hogy nem! Amugy az autocadesek is szivesen ajanlgatnak istentelen osszegert dualaos szervereket, hogy az mijjen jo, es 2-3 eve votl lehtoseg osszehasonlitani egy sima 1 procos gepen, de az istennek sem tunkt lassabnak! asszem 2000 volt! Szoval addig az is csak kamu voilr, hogy qazota mi torten nem tom!:-)))
Az msi-t nytuztuk 2g ecc-vel is igen pozitiv kep volt rola, de ezt mar leirtam!
udv
neduddkihttps://facebook.com/bestwax.eu, mailto: bestwax.eu@gmail.com hamarosan: www.bestwax.eu a lustasag fel egesseg, en tejjesen egesseges akarok lenni
-
marcee
addikt
Több kolléga dolgozik amd-s gépen teljes megelégedéssel ArchiCAD-del és Art*lantis-sal.
Én kitartok az 1db. Barton mellett 2500+ a tuti vétel. Szerintem jelenleg nem érdemes drágábbat venni (itt még nagyon exponenciális az árnövekedés)
A munka nagy részében nem hasznánád ki a többlet sebességet, rendereléskor meg fel lehetne pöckölni az órajelet (msi - fuzzy logic rulz)
A megmaradó léből ram-hegy.\m/
-
-
tadream
csendes tag
Sziasztok! Csak saját tapasztalatból írok, és vádolhattok elfogultsággal! Kb 1.5 éve használok napi 24 órás üzemmódban dual amd xp1700+ konfigurációt. Az alaplap hb. egy éve msi k7d master, előtte tyan 2460 volt. Soha, soha nem térnék vissza egyprocis gépre még akkor sem, mégpedig azért nem, mert rugalmasságban meg sem közelítik a kétprocisokat. Alkalmazásfüggő, hogy a két proci maximális teljesítményt nyújthat-e vagy sem. Ha a progit nem úgy írták, az egyes procik teljesítménye nem megy 50 % fölé, s a renderelés adott esetben nem is lesz gyorsabb, de garantált még akkor is az egyprocis konfigok teljesítménye. Az smp üzemmódba szánt programok 3dmax, Premiere, különböző encoderek kihasználják a két proci nyújtotta többlet teljesítményt, s mindkét proci 100%-on fut. Viszont mindkét esetben megmarad a rugalmasság, olyan még nem volt, hogy belassult volna a gép, mert mindig maradt szabad erőforrás. Igaz, memóriával is ki kell szolgálni a rendszert, de aki ilyen konfigot használ, nem ezen fog spórolni. Ami a melegedést illeti, nem nagyon számít, csak legyen a procikon valami nagyobb felületű borda (nekem zalman 6500AlCu) és kisebb huzat a házban. A hűtőventik 1700 fordulat/perc mennek, gyakorlatilag zajtalanul. Tapasztalat, hogy édes mindegy, a procik épp 55 fokosak, vagy 42! Kicsit összevissza fogalmaztam, lehet, elnézést!
-
dshk
aktív tag
hyperthreadinghez ugyanúgy többszálas program vagy több program kell. De hyperthreading messze nem ugyanaz mint két teljesértékű proci.
-
tocsa
senior tag
Hogyha már UNIX-okat említessz, meg QNX-et látok az aláírásodban, akkor éerdemes lenne megemlíteni a Linuxot. Linuxhoz már nagyon régóta létezik ''cpu affinity'' patch. És ez valóban azt teszi, amit sejt az ember: egy procihoz köt egy adott processzt. Sőt, nemcsak kötni lehet vele procihoz, hanem szabályozni tudod, hogy az adott processz hány százalékosan ragaszkodjon az adott procihoz.
Mellesleg ha már duál procis gép, akkor arra igazából Linux való. Amíg egy duál procis gép esetében teszem azt egy kernel fordítás valóban majdnem kétszeresére gyorsul (!!!), addig sajnos az NT-s kernelek nem skálázódnak ilyen jól a procik számával. Nem láttam erre vonatkozólag hiteles teszteredményeket, de nem kétszeres a gyorsulás. Linuxok esetén 2.4-es kernelről beszélek, amik a 2.2-eshez kernelekhez képest sokkal finomabb, fine grade locking-al rendelkeznek, így igazán barátai az SMP rendszereknek.
Tudom, az ArchiCAD Windowsos program, és nem használja ki az SMP-t. Így tényleg csak akkor érdemes duál procis gépre beruházni, ha mellette állandóan renderelnél Artlantissal. De én is inkább UP gépet vennék, és a különbözetet RAM-ra költeném. Vagy jobb monitorra, ilyesmi.Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz
-
tocsa
senior tag
Na, látom nem válaszol senki. Vegyük sorra.
1. Igen, valóban párhuzamosan, egyszerre futnak. Tehát a CPU-ért a két tasknak (tfh. single thread mind a kettő) nem kell versenyezni, de az egyszeresen rendelkezésre álló erőforrásokért igen (memória, I/O pl. vinyó, CPU busz).
A legjobb, ha egyik CPU/mem intenzív, a másik meg pl. I/O intenzív task. De a vegyes se rossz. Pl. Linuxon kernel fordítás az vegyes, és bizony ha a makefile-ban megnöveled a fordítási batch job-ok számát mondjuk 4-re, akkor ezek által generált gcc és egyéb processzeket az ütemező szépen kiosztja a CPU-k között. Az eredmény majdnem fele idő alatt lefordul a cucc.
Fontos lehet, hogy két processz esetén az ütemező néha fölöslegesen átdobhatja egyik task-ot a másik procira, és a másik task-oit az egyik procira (tehát megcseréli őket). Ha ezek hosszú ideig futó processzek (pl. két renderelés, ilyesmi), akkor erre való a CPU affinity kernel patch, hogy lerögzíthesd őket 1-1 procihoz.
2. Árnyaltabb a helyzet, hogyha a két processznek több thread-je van. Nézzük a Linux kernelt. Ő thread szinten ütemez. A single thread-es processzek egy thread-nek számítanak. Az oprencer ütemezőjének a feladata annak eldöntése, hogy a rendelkezésére álló statisztikai és egyéb adatok alapján eldöntse, melyik thread lesz a következő futó thread a CPU-n, és az mennyi ideig futhat (preemptív ütemező, el is tudja venni a futási jogot). Tehát ott van k darab processz, amik összesen mondjuk m darab thread-ből áll. Az ütemező algoritmus alapján kiválaszt annyi darab thread-et, amennyi CPU van, és akkor azok futnak.
Persze ez nagyon leegyszerűsítve, hogy értsed. A CPU ütemező sok heurisztikát tartalmaz, ami megpróbálja ezt a feladatot minél optimálisabban ellátni. Nem egyszerű dolog, nagyon sok körülményre tekintettel kell lenni.
<Zárójel>
Az ütemezőnek egyik jellemzője, hogy a processzek számától (N) függően mennyi ideig tart egy ütemezési feladat végrehajtása. Ez általában N-nek valamilyen polinom függvénye. pl. O(N^3) // ordó n köb
A jóhír az, hogy a 2.5-ös kernelekben pár híres kernel hacker friss kutatási eredményeket követve O(1)-es ütemezőt írt !!!! Azaz, az ütemezési feladat független a futó processzek számától, konstans. :) !
A másik jó hír, hogy a virtuális memória manager is O(1)-es lesz!!!!
Talán ezeket részben backportolták 2.4-re, nem tudom most, de igazából a 2.6-os kernelben várhatóak teljes fényükban, és szerintem nagyon jók lesznek.
</Zárójel>Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz
Aktív témák
- Otthoni hálózat és internet megosztás
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Yettel topik
- Autós topik látogatók beszélgetős, offolós topikja
- Otthonfelújítási program (2024.)
- Facebook és Messenger
- A régi node-okra koncentrál a szankciók miatt Kína
- Politika
- Kerékpárosok, bringások ide!
- EAFC 24
- További aktív témák...