[i7/Xeon] bedrijfskritische CAD-applicatie

[TerraGuy]

Een kennis van mij heeft een eenmansbedrijf in een nichemarkt, het maken van mallen voor de plastic onderdelen van scheerapparaten, wake-up-lights enzovoort. Het gaat dan om de plastic onderdelen. Deze maakt hij in een CAD-programma, SigmaSoft, en laat ze daar helemaal doorrekenen tot ze kloppen.

Normaal gesproken wordt het programma alleen in grote bedrijven gebruikt, hij is voor zover hij weet de enige die hem als zzp'er gebruikt; het kost dan ook minstens een ton. Via een deal met de makers heeft hij het goedkoop kunnen krijgen. Arm is hij niet, maar bulken van het geld zoals een groot bedrijf doet hij ook niet.

Op het moment heeft hij een quad-core Xeon-workstation staan voor het werken en het rekenen. Het rekenwerk duurt lang, vaak een week, soms 2 of meer voor een beetje een complex product. Het programma schaalt niet heel lekker op met meer core's, al gebruikt hij ze wel. Tis geen 3Dsmax die elke core vol weet te gooien, en tests op 6 cores geven aan dat deze slechts in een enkel geval op alle 6 cores draait, vaak blijft hij op 3,5 niet-helemaal-gevulde core's steken.

Nu is hij dat lange rekenwerk zat, en zoekt een manier om altijd een snel rekenmonster te hebben voor een acceptabele prijs. Die Xeon-workstation gaat al over de 5k, dat is aardig prijzig, zeker omdat hij 'm nu alweer 4 jaar heeft en het veel sneller kan. Kort gezegd: hij wil van het gebruik van Xeon's af als het kan.
Hij kwam met het idee om een Core i7 te kopen met 24GB aan normaal RAM (Xeon heeft ECC), deze zover mogelijk als veilig is over te klokken, en dit grapje dan elk jaar tot 2 jaar opnieuw te doen. Gewoon veel rauwe rekenpower zonder poespas. Dit kost dan 1500 a 2000 per 1 a 2 jaar (nog exclusief verkoop oude pc die dan nog steeds wat opbrengt), en kan hij elk jaar profiteren van de snellere processoren. Hd is minder belangrijk dan RAM en processor, RAID 1 en backups zijn aanwezig en kunnen makkelijk overgezet worden naar nieuwe pc's.

Ik vind het een interessant idee en ik zie de voordelen van de lage prijs en altijd op snelheid zijn, maar voor een bedrijf vind ik het tricky. Je wilt natuurlijk geen vastlopers of fouten in je ontwerpen krijgen. Bij games maakt het niet uit als er wat verkeerd wordt gerendered, maar 0,1mm er naast zitten in een ontwerp is minder mooi. Overklokken en het gebruik van normaal RAM ipv. ECC lijkt me richting 'gevaarlijk' gaan, maar misschien valt het in de praktijk mee, ik weet het niet.

Wat vinden jullie van deze methode? Is een Core i7 geschikt genoeg om de bedrijfskritische CAD-applicatie te draaien in plaats van een Xeon? En als je deze stabiel weet over te klokken tot een veilig niveau, betekent het dat je ook niet meer fouten gaat krijgen in berekeningen? Is het gebruik van ECC noodzakelijk voor CAD, of maakt dat weinig uit in de praktijk? Het zijn toch geen 'live' berekeningen, misschien dat de processor of het programma zelf wel doorkrijgt dat er iets niet klopt, zodat hij de berekening overnieuw kan doen. Of is dat te positief gedacht?

[dion_b]

Klinkt als een typisch stuk dubieus geschreven proprietary software in een nichemarkt. Als ik het zo hoor is de multicore-ontwikkeling van de laatste jaren de heren van SigmaSoft voorbijgegaan, aangezien het niet goed opschaalt. Of niet...

Er is namelijk meer aan de hand dan cores alleen, want als hij 3 cores niet plattrekt, zitten die cores ergens op te wachten. De vraag is waarop...

Wat je zou moeten doen is bepalen wat hier specifiek de bottleneck is. Hoogstwaarschijnlijk een of ander vorm van I/O, dus ofwel geheugenbandbreedte, danwel opslag.

Als het geheugenbandbreedte is, moet dat dus omhoog. De vraag is dan welke quadcore Xeon hij nu heeft ("Xeon" zegt namelijk niet zoveel, Intel verkoopt allerlei zut onder die noemer). Als je met een So1366 i7 meer bandbreedte gaat krijgen dan hij nu heeft, doen. Zo niet ga je er in dit geval op achteruit, en kun je beter kijken naar oplossingen met nog meer bandbreedte (multi-CPU Opteron NUMA-configs ofzo).

Als het om opslag gaat, is het makkelijker, dan wil je gewoon SSDs erin prikken en merk je verschil als dag en nacht. Mogelijk verschuift dan de bottleneck naar geheugen of CPU, maar dat zie je dan wel

Verder mbt stabiliteit - in beginsel is een niet-overclockte i7 (of willekeurig welke andere moderne CPU) exact even stabiel als een Xeon. Of het ontbreken van ECC uitmaakt hangt af van de software, als die met enige vorm van checksums werkt kun je zonder, als het brain-dead is en dat niet doet kan het gebrek aan ECC issues geven. Dat geldt des te sterker als je gaat OCen - als je kunt verificeren of het resulaat coherent is, no problem, zo niet, niet doen.

Maar goed, gezien de huidige CPU nog niet platgetrokken wordt, ook niet een core ervan, denk ik dat je de verkeerde richting op kijkt om de CPU te OCen. Zoek eerst uit waar het nu wel aan ligt en pak dat aan

[TerraGuy]

Interessante punten. Hij trekt core 1 en 2 voller dan 3 en 4, en core 4 staat soms niks te doen. Hij had een test gezien met een nieuwere 6-core Xeon (pricewatch: Intel Xeon X5680) die zijn huidige Xeon (pricewatch: Intel Xeon X5365) voorbij streefde, niet alleen per core, maar ook voller per core. Hij vroeg zich ook al af waar dat aan lag, zijn gok was de cache, maar ook het geheugen zou te langzaam kunnen zijn. De 6-core Xeon ging met een gemiddelde van 3,5 core's (af en toe 6 volle core's ) ongeveer 4x sneller dan z'n eigen 4-core Xeon, die gemiddeld 2,5 core voltrok. Ik zal 's vragen wat het 6-core systeem voor verdere specs had.

Hij heeft als aanvoerschijven een stel relatief nieuwe Seagate Cheetah's 15k RPM in RAID 5 naar ik meen, en hij had het idee dat dat niet het probleem is: de info wordt ingeladen in de 24GB RAM, dus alleen de aanvoer (tussentijds danwel aan het begin) en het wegschrijven zou met SSD's iets sneller gaan, maar hij hoeft niet continu te laden. Ben hier niet helemaal zeker van, maar dit was zijn ervaring (hij werkt er al heel wat jaren mee), hij weet hoeveel RAM er maximaal gebruikt kan worden in een berekening en heeft er zoveel ingestopt, zodat de hd geen beperking meer zou zijn. Ik probeer 'm sowieso een SSD als opstartschijf aan te smeren, kunnen we ook meteen testen of daar een bottleneck ligt.

Het lijkt erop dat de RAM en de cache belangrijk zijn voor het voltrekken van de core's. Dit zou ik 'm kunnen laten testen door de busspeed van z'n RAM naar beneden te draaien, kijken hoeveel % impact dit heeft op workload.
Is er ook een manier om dit met de cache te doen, minder cache te laten gebruiken, zodat ik dat kan laten testen? Hij draait op WinXP 64.

Overigens, dat programma is inderdaad erg niche, het heeft past sinds kort Win7 64-bit ondersteuning, daarvoor was XP 64 het maximale. Vrij klote om daarmee te werken. En pas vrij laat multicore-ondersteuning, officieel ondersteunden ze tot voor kort max 2, misschien werken ze daar ondertussen al aan. Tis alsof bedrijven maar moeten slikken wat ze doen, ze zijn d'r van afhankelijk en SigmaSoft heeft blijkbaar verder weinig concurrentie, zodat ze niet heel vlot vernieuwen. Nou ja, hij moet ook gewoon dat programma gebruiken, andere programma's heeft hij geprobeerd, maar deze werkt toch het best, zij het met fratsen.

[Verwijderd]

Ik Zou het hem zeker afraden. Sinds dat de pc non-stop aanstaat zou hij zeker willen opteren voor ECC ram omdat dit soort ram ervoor zorgd dat de data veiliger opgeslagen wordt op de ram latjes.

Ten tweede is het af te raden omdat Xeon processor net iets beter zijn in het berekenen van lange string-codes, en dat is net wat hij aan het doen is. Xeon processor zijn duurder omdat ze dan ook bepaalde technieken beter aankunnen. Als je CAD doet op een normale cpu gaat je pc koken binnen enkele uurtjes.

Als ik hem was kocht ik voor nog eens 4 jaar een 12-core xeon met evga sr-2 met ecc ram. Dit zal hem wel flink wat kosten, maar het is zeker de moeite waart.

Hij kan ook net zo goed een ander multi core MB kopen maar de evga laat toe dat hij hier met gemak kan gaan overclocken (namenlijk van @3.33 tot ruim @4.67 Ghz)

Verder mag hij zeker de cooling niet vergeten, miscchien moet hij eens liquid cooling gaan overwegen met enkele stukken, zo weet hij zeker dat zijn system het nooit begeefd, en nooit een melted cpu part krijgt.

Ik hoop dat deze raad je iets bij brengt.

[jbkappirossi]

wacht nog even op BULLDOZER 16core. en de nieuwe 16 threaded SANDY BRIDGE.

[SouLLeSSportal]

Ik zou ook nog even afwachten op dit moment, er komen net weer nieuwe cpu's van beide kampen op de markt komende half jaar. De nieuwe sandy bridge voor socket 2011 zal ook vast wel een zakelijke variant krijgen.
AMD krijgt ook een vernieuwde cpu reeks, zoals al gezegd oa de bulldozers.

Verder klinkt het vooral dat de software gewoon nog brak is.

[ Voor 10% gewijzigd door SouLLeSSportal op 12-03-2011 11:27 ]

[ZeRoC00L]

SouLLeSSportal schreef op zaterdag 12 maart 2011 @ 11:26:
Ik zou ook nog even afwachten op dit moment, er komen net weer nieuwe cpu's van beide kampen op de markt komende half jaar.

Ja, en over een half jaar worden er weer nieuwe CPUs aangekondigd, kun je blijven wachten....

[dion_b]

TerraGuy schreef op zaterdag 12 maart 2011 @ 02:00:
Interessante punten. Hij trekt core 1 en 2 voller dan 3 en 4, en core 4 staat soms niks te doen. Hij had een test gezien met een nieuwere 6-core Xeon (pricewatch: Intel Xeon X5680) die zijn huidige Xeon (pricewatch: Intel Xeon X5365) voorbij streefde, niet alleen per core, maar ook voller per core. Hij vroeg zich ook al af waar dat aan lag, zijn gok was de cache, maar ook het geheugen zou te langzaam kunnen zijn. De 6-core Xeon ging met een gemiddelde van 3,5 core's (af en toe 6 volle core's ) ongeveer 4x sneller dan z'n eigen 4-core Xeon, die gemiddeld 2,5 core voltrok. Ik zal 's vragen wat het 6-core systeem voor verdere specs had.

Begin eens met appels van peren te onderscheiden

Deze CPUs verschillen op veel meer dan alleen hoeveel cores ze hebben...

De X5365 is een 65nm Core2 ontwerp, met nog een ouderwetse FSB en off-die geheugencontroller. Feitelijk is het een Q6600 die van 1066MT/s naar 1333MT/s FSB overclocked is. Dat is gelijk ook z'n maximale geheugenbandbreedte.

De X5680 is een Westmere (32nm shrink van Nehalem Core i7) ontwerp met QPI-bus waar geen geheugen overheen moet en on-die triple channel geheugencontroller die 3x 1333MT/s haalt, dus het drievoudige van z'n huidige X5365

Het feit dat maar vier van de zes cores in de regel gebruikt worden zegt dat de processing power van de CPU niet de primaire bottleneck is, maar nadrukkelijk de geheugenbandbreedte. Ik vermoed dat de performance van deze app liniair schaalt met geheugenbandbreedte als ik het zo hoor. Ik trek overigens bij dezen iedere negatieve opmerking over SigmaSoft in, hun app kan blijkbaar wel prima doorschalen naar meer cores, mits de I/O (geheugen) het maar bij kan benen


Volgende vraag: moet je zo'n dure X5680 Xeon kopen om diezelfde bandbreedte te realiseren? Nope. Binnen de Xeon-familie heb je het al met een quadcore X5647, wat al 40% goedkoper is dan de X5680, maar als je genoegen neemt met 2.4x de huidige geheugenbandbreedte kun je voor EUR 254, dus eenzesde van de prijs van de X5680, 80% van de verbetering ervan behalen. Natuurlijk moet hier ook een moederbord en geheugen bij, maar ik gok dat EUR 1200 op CPU besparen wel redelijk aantikt

Hij heeft als aanvoerschijven een stel relatief nieuwe Seagate Cheetah's 15k RPM in RAID 5 naar ik meen, en hij had het idee dat dat niet het probleem is: de info wordt ingeladen in de 24GB RAM, dus alleen de aanvoer (tussentijds danwel aan het begin) en het wegschrijven zou met SSD's iets sneller gaan, maar hij hoeft niet continu te laden. Ben hier niet helemaal zeker van, maar dit was zijn ervaring (hij werkt er al heel wat jaren mee), hij weet hoeveel RAM er maximaal gebruikt kan worden in een berekening en heeft er zoveel ingestopt, zodat de hd geen beperking meer zou zijn. Ik probeer 'm sowieso een SSD als opstartschijf aan te smeren, kunnen we ook meteen testen of daar een bottleneck ligt.

Als ik dit zo hoor heb je gelijk en maakt I/O van schijf naar geheugen weinig tot niets uit, zeker niet gezien het verschil dat een andere geheugenarchitectuur duidelijk maakt.

Het lijkt erop dat de RAM en de cache belangrijk zijn voor het voltrekken van de core's. Dit zou ik 'm kunnen laten testen door de busspeed van z'n RAM naar beneden te draaien, kijken hoeveel % impact dit heeft op workload.

Mijn voorspelling: volledig liniair. Als hij dus FSB 25% verlaagt gaat z'n tijdsduur 25% omhoog.

Is er ook een manier om dit met de cache te doen, minder cache te laten gebruiken, zodat ik dat kan laten testen? Hij draait op WinXP 64.

Eerlijk gezegd denk ik dat dit totaal gerommel in de marge is. Het is sowieso ook appels en peren vergelijken tussen verschillende CPU architecturen - bedenk dat je hier te maken hebt met een huidige CPU die gewoon twee dual core dies in één package zijn, elk met eigen L1 en L2 cache en verbonden met FSB, terwijl de Nehalem/Westmere een native quadcore die heeft met L1, L2 en L3 cache, en met een on-die geheugencontroller die dus niet van FSB afhankelijk is. Alleen al het verschil tussen 2 en 3 lagen cache maakt dat je de getallen niet 1-op-1 kunt vergelijken. Ik zou hier geen tijd in steken.

Overigens, dat programma is inderdaad erg niche, het heeft past sinds kort Win7 64-bit ondersteuning, daarvoor was XP 64 het maximale. Vrij klote om daarmee te werken. En pas vrij laat multicore-ondersteuning, officieel ondersteunden ze tot voor kort max 2, misschien werken ze daar ondertussen al aan. Tis alsof bedrijven maar moeten slikken wat ze doen, ze zijn d'r van afhankelijk en SigmaSoft heeft blijkbaar verder weinig concurrentie, zodat ze niet heel vlot vernieuwen. Nou ja, hij moet ook gewoon dat programma gebruiken, andere programma's heeft hij geprobeerd, maar deze werkt toch het best, zij het met fratsen.

Eerlijk gezegd vind ik dit nog lang zo slecht nog niet klinken. Je hebt het over zulk specifieke software dat het aanpassen van OS en hardware aan de applicatie normaal is, XP64 support is niet eens zo brak of oud, multicore en dus multithreading werkt duidelijk, ook al is het nogal RAM-limited en zeggen ze maar tot twee cores te ondersteunen.

Verwijderd schreef op zaterdag 12 maart 2011 @ 09:35:
Ik Zou het hem zeker afraden. Sinds dat de pc non-stop aanstaat zou hij zeker willen opteren voor ECC ram omdat dit soort ram ervoor zorgd dat de data veiliger opgeslagen wordt op de ram latjes.

Sinds wanneer werd RAM voor opslag gebruikt? Daar heb je de harde schijven voor. Data wordt alleen in RAM geladen als het direct in bewerking nodig is. Dat gezegd, ECC is bij dit soort lange bewerkingstijd met veel data noodzakelijk - de kans dat ergens een bitje flipt bij een weeklang renderen is namelijk best hoog. Wederom de vraag: TerraGuy, heeft deze programma een of andere vorm van integrity checking om te bevestigen of berekende uitkomsten valide zijn? Zo niet is ECC een must, zo ja kun je op zich zonder.

Ik denk trouwens dat met de prijs van de W3520 het niet zinnig is om hierop te bezuinigen - de W3520 is niets meer of minder dan een Core i7 920, maar dan met ECC support. En de meerprijs tov de 920? Welgeteld EUR 7

Op hogere snelheden is het verschil wel groter, als je dus per se die 3x 1333MT/s RAM wilt zul je voor een W3570 of X5550 moeten gaan, die rond de EUR 900 kosten. Er is trouwens geen Core i7 die in-spec 1333MT/s haalt, daarvoor moet je sowieso gaan overclocken (wat je IMHO net zo goed met de i7 920 kunt doen).

Voor overclocken geldt nog sterker hetzelfde als voor ECC: als integrity checking in software goed is, kun je je eraan wagen, zo niet, NIET doen

Ten tweede is het af te raden omdat Xeon processor net iets beter zijn in het berekenen van lange string-codes, en dat is net wat hij aan het doen is. Xeon processor zijn duurder omdat ze dan ook bepaalde technieken beter aankunnen. Als je CAD doet op een normale cpu gaat je pc koken binnen enkele uurtjes.

Pardon Jij gelooft zeker ook wat Intel roept over hoe een nieuwe CPU van hen je bedrijf beter beveiligt?

Het gros van de Xeon CPUs heeft exact dezelfde core en vaak exact dezelfde die als de desktoptegenhangers ervan. Het enige verschil is dat Intel gekozen heeft om bepaalde functionaliteiten aan of uit te zetten, zoals bijvoorbeeld ECC functionaliteit die alleen bij Xeon aangezet wordt. Verder zijn de i7 920 en W3520 echt *exact* dezelfde CPU, met dezelfde TDP (thermal design power), dezelfde kloksnelheden enz enz enz.
Bij de X-series Xeons staat bijvoorbeeld SMP (multi-CPU) functionaliteit aan. Dat is ook een optie die gewoon aanwezig is in de W-series Xeon en in de residentiele i7-series, maar daar op keuze van Intel's marketingafdeling uitgeschakeld staat.

Als ik hem was kocht ik voor nog eens 4 jaar een 12-core xeon met evga sr-2 met ecc ram. Dit zal hem wel flink wat kosten, maar het is zeker de moeite waart.

Als ik hem was zou ik blij zijn dat jij niet degene bent die dit voor hem uitzoekt. Uit de gegevens die TerrraGuy al voor jouw post gemeld had duidelijk is, worden bij een 6-core niet eens alle cores gebruikt, dus is de meerprijs voor nog eens 6 cores volstrekt onzinnig. Waar het om gaat is geheugenbandbreedte, geheugenbandbreedte en nog eens geheugenbandbreedte. Zoals je ziet raad ik om die reden alsnog een Xeon aan, maar dan gericht en niet zomaar de duurste omdat duurst altijd het beste zou zijn oid

Hij kan ook net zo goed een ander multi core MB kopen maar de evga laat toe dat hij hier met gemak kan gaan overclocken (namenlijk van @3.33 tot ruim @4.67 Ghz)

Wacht even, je vindt het onverantwoord om geen ECC te draaien (zit wat in), maar vervolgens raad je wel aan om lekker te OCen? Niet echt consequent...

Wederom, of dit aan te raden is hangt totaal af van in hoeverre de software evt optredende fouten kan opsporen. Zo ja, doen. Zo nee, laten.

Verder mag hij zeker de cooling niet vergeten, miscchien moet hij eens liquid cooling gaan overwegen met enkele stukken, zo weet hij zeker dat zijn system het nooit begeefd, en nooit een melted cpu part krijgt.

Waterkoeling is efficent en stil, dus eens dat het zeker het overwegen waard is, maar "zeker dat zijn system het nooit begeefd [sic]" ben je nooit, ook waterkoeling is feilbaar en dan heb je net zo'n meltdown als met luchtkoeling. Als je je zorgen maakt om uitval koeling (wat idd bij wekenlang 24/7 onder full load draaiend een issue kan zijn) moet je zorgen voor alarmering bij uitval fans (of pompen). In het categorie moederbord waar we het hier over hebben zit dat standaard in BIOS. Je moet alleen zorgen dat de nodige opties aanstaan.

SouLLeSSportal schreef op zaterdag 12 maart 2011 @ 11:26:
Ik zou ook nog even afwachten op dit moment, er komen net weer nieuwe cpu's van beide kampen op de markt komende half jaar. De nieuwe sandy bridge voor socket 2011 zal ook vast wel een zakelijke variant krijgen.
AMD krijgt ook een vernieuwde cpu reeks, zoals al gezegd oa de bulldozers.

AMD is een optie die TS nog niet overwogen heeft en wel eens zeer zinnig zou kunnen zijn.

Per-thread en per-core heeft AMD op dit moment niets dat in de buurt komt van de Nehalem-architectuur van Intel. Maar we hadden al geconstateerd dat deze software niet CPU-limited is, dus dat is minder interessant. Veel relevanter is geheugenbandbreedte, en laat dat nou net iets zijn waar AMD in de high-end een voordeel heeft. Zo zou je rond de 4x 1333MT/s kunnnen halen hiermee. Om die voordeel te behalen zul je trouwens nadrukkelijk twee CPUs moeten gebruiken bij een AMD-platform. Gelukkig zijn Opteron 4xxx-series CPUs voor rond de EUR 200 te krijgen, dus is dat nog niet onoverkomelijk.

Wel constateer ik een afgrijselijk tekort aan fatsoenlijke Opteron 4xxx-series benchmarks (enige die ik vind met redelijke vergelijking is bij AMD zelf, met dus hoog WC-eend gehalte en sowieso geen vergelijking met de Xeons die we hier bespreken. Je zult dus een benchmark van het SigmaSoft CAD-programma moeten krijgen om het zeker te weten. Ik zou eens gaan vissen, want m'n onderbuik zegt dat een tweetal Opteron 4180's die samen EUR 320 kosten wel eens meer bandbreedte zouden kunnen leveren dan een Xeon X5550. Samen zouden de acht Opteron cores ook evenveel werk kunnen verrichten als de vier Xeon cores, enige vraag is dan of de hogere single-thread performance van de Xeon doorslag geeft, en dat hangt puur af van hoe de app geschreven is...

Verder klinkt het vooral dat de software gewoon nog brak is.

Nou nee, als ik deze cijfers lees klinkt het vooral alsof de software zeer afhankelijk is van één variabele, namelijk geheugenbandbreedte, maar binnen die beperking prima z'n best doet en niet onderdoet voor een 3DSMax. Enige reden waarom 3DSMax de cores wel voltrekt en dit CAD-geval niet is omdat 3DSMax minder geheuenbandbreedte nodig heeft, en dat ligt vrijwel zeker aan wat het doet, niet hoe het geprogrammeerd is

[johnkeates]

Kan het programma rekenwerk niet uitbesteden? Bijvoorbeeld render nodes of een 3rd party systeem?

Even snel gezocht, maar dat lijkt niet te kunnen. Dat wordt gewoon kijken naar een beetje een enterprise mobo met twee sockets waar je dan ook twee Xeon's met QPI in kan stoppen, waarna je dan daar weer 32GB ram in kan steken om zo al het geheugen zo snel mogelijk aan te kunnen spreken.


Weer even snel gezocht, een S5520SC van Intel is een van de geschiktere mobo's.

2x LGA1366 socket

Max Memory Size (dependent on memory type): 192 GB
Memory Types: DDR3 ECC UDIMM, RDIMM
Memory slots: 12

Daar zou je dan twee X5677's in kunnen stoppen.

En nog even prijzen:

- S5520SC = 325 USD
- X5677 = 1660 USD

Dan zit je al op 2x1660+325 USD en moet je nog een 1.5 - 2 Kw voeding, een vrij grote kast (groter dan bijv. de Cooler Master Cosmos), en RAM.

RAM:

CT3KIT204872BB1067Q voor maximale hoeveelheid (16Gx3 Kit DDR3 PC3-8500) @ 2549.99 USD
CT3KIT102472BV1339 voor maximale snelheid (8Gx3 Kit DDR3 PC3-10600) @ 1001.99 USD

Dus stel dat je 12 slots wil vullen:

4x CT3KIT204872BB1067Q = 10200 USD = 192 GB
4x CT3KIT102472BV1339 = 4008 USD = 96 GB


En zo kan er nog wel e.e.a. bijeen gezocht worden. De onderdelen die ik hier post zijn allemaal gecontroleerd en staan op elkaars QVL's. Dat dat mobo in 2009 gelreased was doet geen negatieve dingen met de performance; probeer maar eens ergens anders een WS mobo te vinden met dezelfde specs

[ Voor 123% gewijzigd door johnkeates op 12-03-2011 14:47 ]

[dion_b]

Ben ik nou de enige die ziet dat het o geheugenbandbreedte gaat

johnkeates, wat denk je exact dat deze X5677 en aanbieden die een W3520 niet bieden tov huidige CPU?

En wat gaat 32GB tov 24GB opleveren als hij nu al alles in RAM kwijt kan, dus niet naar schijf zit te thrashen

[Tweak-Freak]

Het eerste wat ik zou doen is contact op nemen met de ontwikkelaar van deze software en vragen wat de ideale verhouding io geheugen en cpu pouwer is. Ik neem aan dat ze daar zeer uitgebrijd hun eigen software tesen en dus exact weten waar de kracht en zwakheden van hun pakket ligt.

Als het inderdaat vooral om geheugenbandbreedte gaat, wat mij ook zeer aannemlijk lijkt dan heeft dion_b een zeer goed onderbouwde uiteenzetting gegeven van de beste opties.

[catfish]

ik denk dat dion_b wel eens gelijk zou kunnen hebben over het geheugengebruik
in dat geval wil je dus de goedkoopste Xeon met de snelste bus wat op dit moment de X5650 is (6,4 GT/s), de W3520 heeft maar 4,8 GT/s
het prijsverschil is echter enorm...
het zou natuurlijk kunnen dat een 4,8 GT/s QPI ruim voldoende is en dat het probleem bij het ram zit, beide kunnen triple channel aan (de X5365 heeft maar dual channel)

zelf heb ik op het werk ook een programma dat niet ideaal schaalt (bij ons is het extreem moeilijk multi-threaded te maken) en wij zijn in de richting aan het werken om gewoon meerdere runs tegelijk te draaien op 1 PC
in dit geval is de geheugenbandbreedte een probleem, is het geen idee om 2 goedkopere PC's te kopen?
het zal zo snel niet zijn per stuk (je moet dat wel 2 licenties hebben natuurlijk), maar er zal zeker een winst zijn

blijven wachten op een nieuwe generatie is misschien raar advies, dat ik normaal niet zou geven, maar die 6,4 GT/s is al 2-3 jaar het maximale wat intel biedt, de nieuwe generatie (s2011) zal waarschijnlijk wel een serieuze verbetering hebben
en met Bulldozer voor de deur, zou ik ook wel even naar AMD kijken

ECC lijkt mij inderdaad wel een must, overklokken lijkt mij echter totaal overbodig tenzij je ook de QPI-bus kan overklokken (dat weet ik niet)
of misschien is de hoeveelheid data zo groot dat het cache niet efficiënt kan werken waardoor de cpu constant moet wachten op het ram, misschien dat ram met betere specificaties dan erg nuttig zijn?

[dion_b]

catfish schreef op zaterdag 12 maart 2011 @ 23:00:
ik denk dat dion_b wel eens gelijk zou kunnen hebben over het geheugengebruik
in dat geval wil je dus de goedkoopste Xeon met de snelste bus wat op dit moment de X5650 is (6,4 GT/s), de W3520 heeft maar 4,8 GT/s
het prijsverschil is echter enorm...
het zou natuurlijk kunnen dat een 4,8 GT/s QPI ruim voldoende is en dat het probleem bij het ram zit, beide kunnen triple channel aan (de X5365 heeft maar dual channel)

Bus en RAM staan in beginsel bij een CPU met integrated geheugencontroller los van elkaar. Een snelle QPI is leuk, maar alleen relevant als de bottleneck daar zit.

De QPI van de X5650 is misschien 33% sneller dan die van de W3520, maar z'n geheugenbandbreedte is slechts 25% meer.

Ter vergelijking, de W3520 biedt nog steeds 2.4 keer meer geheugenbandbreedte dan de X5365 die hij nu heeft

zelf heb ik op het werk ook een programma dat niet ideaal schaalt (bij ons is het extreem moeilijk multi-threaded te maken) en wij zijn in de richting aan het werken om gewoon meerdere runs tegelijk te draaien op 1 PC
in dit geval is de geheugenbandbreedte een probleem, is het geen idee om 2 goedkopere PC's te kopen?
het zal zo snel niet zijn per stuk (je moet dat wel 2 licenties hebben natuurlijk), maar er zal zeker een winst zijn

Mits het goed te distribueren is. En als hij het over een reguliere prijs van een ton heeft, vrees ik dat "goedkoop" nog altijd niet in de categorie van een paar tientjes per licentie is...

Een AMD NUMA-setup komt in de buurt van wat je hier voorstelt, maar dan in een enkel systeem.

blijven wachten op een nieuwe generatie is misschien raar advies, dat ik normaal niet zou geven, maar die 6,4 GT/s is al 2-3 jaar het maximale wat intel biedt, de nieuwe generatie (s2011) zal waarschijnlijk wel een serieuze verbetering hebben
en met Bulldozer voor de deur, zou ik ook wel even naar AMD kijken

Mwoeah, de volgende generatie zal altijd iets meer bieden, de enige reden dat Intel stil lijkt te staan qua QPI en geheugenbandbreedte is simpelweg dat zeer weinig toepassingen daadwerkelijk daarop bottlenecken, ze breiden in de tussentijd wel vrolijk het aantal cores uit, wat een veel vaker voorkomende beperking is.

ECC lijkt mij inderdaad wel een must, overklokken lijkt mij echter totaal overbodig tenzij je ook de QPI-bus kan overklokken (dat weet ik niet)
of misschien is de hoeveelheid data zo groot dat het cache niet efficiënt kan werken waardoor de cpu constant moet wachten op het ram, misschien dat ram met betere specificaties dan erg nuttig zijn?

Volgens mij vergeet je weer dat RAM bij een Nehalem niet over de QPI-bus gaat. Dat ding wordt alleen gebruikt voor verkeer tussen CPUs (niet relevant bij single-CPU) en voor de PCIe 16x sloten, die hier helemaal niets doen.

Het gaat om geheugenbandbreedte, die kun je omhoogkrikken door de geheugenbus hoger te klokken. Allicht dat het EVGA bord wat SimplexH305 noemt daar veel opties voor heeft. Toch vraag ik me af in hoeverre het verstandig is als de software geen data integrity checks heeft. ECC vangt weliswaar fouten in het geheugen zelf op, maar niet dingen in de geheugencontroller.

[vanaalten]

dion_b schreef op zaterdag 12 maart 2011 @ 01:19:
Of het ontbreken van ECC uitmaakt hangt af van de software, als die met enige vorm van checksums werkt kun je zonder, als het brain-dead is en dat niet doet kan het gebrek aan ECC issues geven.

Dat ben ik nu al een paar keer tegengekomen. Mis ik iets, of klopt dit gewoon niet? Bij mijn weten wordt bij DRAM geheugen van PC's (dus ook DDR3 en zo) de error correctie/detectie door de hardware, memory controller gedaan. Zo wordt het in elk geval ook op Wikipedia uitgelegd.

Lijkt mij maar beter ook, voor de hardware stelt dit geen moer voor (wat exclusive-or poortjes, praktisch niets t.o.v. de complete memory controller), voor software zou dit een enorme performance penalty geven. Ofwel, volgens mij maakt de software hier niets uit voor de ECC keuze.

(overigens heb ik geen idee hoevaak er nou 'spontaan' bits omvallen, en of je dus in de praktijk die ECC echt nodig hebt...)

[dutch_warrior]

ZeRoC00L schreef op zaterdag 12 maart 2011 @ 12:11:
[...]

Ja, en over een half jaar worden er weer nieuwe CPUs aangekondigd, kun je blijven wachten....

Een AMD interlagos (Opteron bulldozer) platform zou in theorie erg goed moeten zijn met applicaties zoals TerraGuy beschrijft. Het is alleen even afwachten op de eerste betrouwbare benchmarks om te zien hoe het bijvoorbeeld zit met de geheugen bandbreedte, volgens mij heeft dion_b namelijk wel gelijk en is dit de beperkende factor voor deze applicatie.

Ik ben van mening dat het nu niet het juiste moment is om een high end workstation te kopen, de cpu's welke er nu aankomen zijn weer een nieuwe generatie (bulldozer in ieder geval) en zouden in theorie een flink stuk sneller moeten zijn als de huidige generatie. De cpu die na bulldozer komt is waarschijnlijk een geoptimaliseerde bulldozer cpu en zal hoogstwaarschijnlijk dus ook minder performance winst bieden ten opzichte van de eerste bulldozer cpu's en in dat geval zou wachten dus inderdaad niet de moeite waard zijn.

@van aalten:
ECC is een nuttige feature maar bij erg kritische applicaties zou ik niet puur op ECC vertrouwen, als ECC perfecte bescherming zou bieden zouden zaken als ZFS overbodig zijn, bitjes kunnen echter ook omvallen op momenten dat ECC er geen vat op heeft.
ECC kan zeker wel problemen voorkomen maar ik zou toch in een applicatie wel enige vorm van controle inbouwen en niet alles laten afhangen van de hardware waarop de applicatie draait.

[ Voor 17% gewijzigd door dutch_warrior op 13-03-2011 02:11 ]

[Verwijderd]

De memory controller moet er mee kunnen omgaan, dat is een ja. Maar het is ook een extra chipje op de Dimm (welke ook staat in je link). Normaal heb je 8 chipjes, bij ECC zijn het er 9, het is dus niet alleen een kwestie van de controller.

[dion_b]

vanaalten schreef op zondag 13 maart 2011 @ 01:29:
[...]

Dat ben ik nu al een paar keer tegengekomen. Mis ik iets, of klopt dit gewoon niet? Bij mijn weten wordt bij DRAM geheugen van PC's (dus ook DDR3 en zo) de error correctie/detectie door de hardware, memory controller gedaan. Zo wordt het in elk geval ook op Wikipedia uitgelegd.

Lijkt mij maar beter ook, voor de hardware stelt dit geen moer voor (wat exclusive-or poortjes, praktisch niets t.o.v. de complete memory controller), voor software zou dit een enorme performance penalty geven. Ofwel, volgens mij maakt de software hier niets uit voor de ECC keuze.

Juist wel. ECC wordt inderdaad helemaal in hardware afgehandeld, en het moge duidelijk zijn dat je veel minder kans op errors hebt bij ECC dan zonder ECC.

De vraag is alleen wat de gevolgen zijn van zo'n error, en daar speelt software een grote rol.

Als er een single bit error optreedt in de text die ik nu typ lees je een andere letter. Hoogstwaarschijnlijk lees je daar overheen: de software in je hoofd heeft vanzelf de error gecorrigeerd. Als je er niet overheen leest / kunt lezen valt het wel op, de software in je hoofd heeft het gedetecteerd. Het is pas een echt probleem als de fout er doorheenglipt zonder detectie of correctie. In dit voorbeeld zou dat zijn als de fout er aannemelijk uitziet, omdat de andere letter net zo goed in een bestaand woord past.

In computertermen kun je iets vergelijkbaars doen. Je kunt dmv checksums controleren of de resultaat van een berekening zinnig is. Stel je vermenigvuldigt een even getal met een oneven getal. Als daar een oneven getal uitkomt weet je dat iets fout gegaan is. Zo bestaan er nog veel meer vormen van controles die je op uitkomsten kunt loslaten. Dat is zeker bij dit soort software geen overbodige luxe, want als je letterlijk wekenlang aan het rekenen bent is de kans op fouten in het gehele proces (CPU, chipset, RAM) aanwezig, ook al gebruik je ECC.

Als die checks er dus in zitten, zijn de gevolgen van een fout beperkt, omdat je minimaal kunt detecteren als er iets fout gaat. Dat betekent nog eens de rendering draaien (waar je niet vrolijk van wordt), maar tenminste weet je dat je geen bagger gaat aanleveren voor productie.

(overigens heb ik geen idee hoevaak er nou 'spontaan' bits omvallen, en of je dus in de praktijk die ECC echt nodig hebt...)

Leesvoer:
http://arstechnica.com/bu...ut-errors-upside-down.ars

The headline conclusion in the study is that DRAM errors are vastly more common than is typically assumed. Nearly one-third of the individual machines in the study saw at least one error per year, a rate that's orders of magnitude higher than previous research had indicated.

[johnkeates]

X5677 vs W3520 komt vooral neer op cache, QPI en RAM, de W kan bijv. slechts 24GB ram adresseren, terwijl de X tot 200GB+ kan. De QPI is *wat* sneller en de cache is een paar MB groter. Stel dat bijv. de QPI of hoeveelheid RAM in totaal een bottleneck zou zijn, is het een vrij grote versnelling. Als dat niet het geval is, is het daar dus niet te zoeken.

Het probleem in dit geval is dus dat het niet bekend is waar mee het programma sneller zou kunnen draaien. Een CPU die harder gaat, dat is een ding, maar meer cores, meer RAM, snellere busses, bredere busses, ECC/geen ECC enz enz, het zijn allemaal leuke dingen (net als een dual socket mobo en NUMA en 192GB RAM), maar allemaal bedenksels die snel zijn maar misschien het sigma programma niet versnellen. Eerst maar eens uitvinden wat dat programma nodig heeft alvorens meer over hardware setups te bedenken?

[TerraGuy]

Thanks voor alle input. Het blijkt dat de software officieel maximaal 2 cores ondersteund, de rest is blijkbaar 'beta', of ze kunnen het gewoon niet garanderen dus ze dekken zich in. Er is slechts één onderdeel die wel alle cores voltrekt, en de rest hangt tussen de 1 en de 3 in. Bij sommige onderdelen moeten de resultaten gedeeld worden, dat zou kunnen verklaren waarom een core dan soms niks staat te doen. Overklokken zou dan ook zeker lineair meeschalen. Helemaal als je daarmee meer geheugenbandbreedte kunt pakken.

Er wordt nog flink gewerkt aan het programma, dus het zal in de nabije toekomst beter worden met de multicore-ondersteuning is de verwachting. Het is wel lastig om het bedrijf vragen te stellen over niet-officieel ondersteunde zaken denk ik. Ook zijn er maar enkele Xeon-pc's van Dell en HP die officieel ondersteund worden, i7 enzo niet. Maar een vraag als: 'wat is de meest snelle oplossing op dit moment en waarom', en 'zou een pc met meer geheugenbandbreedte ook zorgen voor een veel sneller eindresultaat' zouden een poging waard zijn om te stellen.

Het rekenwerk van het programma is vrij rechttoe-rechtaan C-programmering zonder interactie met de rest van de pc. Het programma draait ook op UNIX-systemen. Het is een optie om daar naar te kijken, al denk ik niet dat hij daar verstand van heeft of mensen heeft die daar verstand van hebben. Ik weet er niets van, en weet daarom ook niet of het voordelen biedt boven Windows. Het lijkt me niet aangezien het toch een kwestie van processorpower en geheugen/geheugenbandbreedte is. Maar ik kan het mis hebben.

Het programma gebruikt zelf ook checksums, waarmee de noodzaak van ECC kleiner wordt.

Het wordt een zaak om dus wat meer te testen om te weten wat de handigste upgrade-strategie is voor nu en de toekomst. Het programma zit vol met beveiligingen, ook nog een dongle enzo, ik zal 's vragen of het mogelijk is om het op andere systemen te installeren, of dat er voor elk systeem een nieuwe code moet worden opgevraagd bij sigmasoft waardoor die mogelijkheid beperkt is.

[nedernakker]

als het dan echt niet multi core schaalt, ben je momenteel het beste af met een Sandy bridge core i7.. klok voor klok het snelst en de turbo voegt natuurlijk behoorlijk wat toe.. ik zou het ook niet maximaal overklokken, maar de turbo multi bijvoorbeeld op 40 zetten.

nadeel is wel dat je maximaal 16 GB geheugen kwijt kunt (ik heb nog geen 8GB modules gezien), ik weet niet in hoeverre dit beperkend is voor de software...

eventueel een sloot SSD's erin in RAID 5 en dan ben je denk ik wel aardig aan de max..

[dutch_warrior]

Als het echt zo slecht schaalt over meerdere cores zou ik even wachten tot juni dan is duidelijk wat de performance is van de nieuwe cpu's.
AMD interlagos biedt op papier meer geheugen bandbreedte en kan met Turbo 2.0 ook afzonderlijke cores on demand schalen naar een geteste maximale frequentie. Interlagos is een opteron platform (6000) en omdersteund dus ECC ram en multisocket configuraties, mocht de applicatie dan in de toekomst beter schalen dan kan er voor weinig geld nog wat spul bijgezet worden.

Een desktop cpu met turbo zou ik vanwege het gebrek aan ECC support niet gebruiken.
Er komen ook weer nieuwe Xeons aan welke ook meer bandbreedte zouden bieden.

[InFamous]

Waarom renderd hij dan niet vanaf zijn Gpu ipv Cpu?

[Verwijderd]

Misschien andere software?
Heb zoiets ook eens gedaan, model in 3d getekend in Autocad en daarna geïmporteerd in Mastercam.
Mastercam geeft hierbij keurig de fouten in de tekening aan, en kan als de tekening goed is de machines aansturen om het model te maken.
Is al een aantal jaren geleden dat ik dat deed, maar het werkte eigenlijk best wel snel ( natuurlijk afhankelijk van het model)
Deze combinatie zal ook goedkoper zijn denk ik

[dion_b]

TerraGuy schreef op zondag 13 maart 2011 @ 05:34:
Thanks voor alle input. Het blijkt dat de software officieel maximaal 2 cores ondersteund, de rest is blijkbaar 'beta', of ze kunnen het gewoon niet garanderen dus ze dekken zich in. Er is slechts één onderdeel die wel alle cores voltrekt, en de rest hangt tussen de 1 en de 3 in. Bij sommige onderdelen moeten de resultaten gedeeld worden, dat zou kunnen verklaren waarom een core dan soms niks staat te doen. Overklokken zou dan ook zeker lineair meeschalen. Helemaal als je daarmee meer geheugenbandbreedte kunt pakken.

De vraag is of op zo'n moment de 1 of 2 cores wel op 100% staan. Wat je tot nu toe schreef deed het voorkomen alsof dat niet zo is. Op moment dat de cores niet op 100% zitten geldt wat ik hierboven geschreven heb mbt geheugenbandbreedte, op moment dat die paar cores *wel* op 100% zitten wordt het een ander verhaal, dan is namelijk de single-thread performance de bottleneck en zou je iets kunnen bereiken door te overclocken...

Maar...

Ik twijfel sterk of dat het geval is. Je geeft aan dat het verschil tussen een X5365 en een X5680 een factor vier is. De single-thread performance van een X5680 is zonder meer beter dan de X5365, maar zeker niet vier keer beter

Het enige verschil tussen die twee dat in die orde van grootte is, is geheugenbandbreedte. Allicht dat de betere single-thread performance en de extra twee cores (voor op momenten dat het wel goed threaded werkt) het verschil uitmaken tussen een factor 3 en een factor 4, maar de hoofdmoot van het verschil is geheugenbandbreedte.

Er wordt nog flink gewerkt aan het programma, dus het zal in de nabije toekomst beter worden met de multicore-ondersteuning is de verwachting. Het is wel lastig om het bedrijf vragen te stellen over niet-officieel ondersteunde zaken denk ik. Ook zijn er maar enkele Xeon-pc's van Dell en HP die officieel ondersteund worden, i7 enzo niet. Maar een vraag als: 'wat is de meest snelle oplossing op dit moment en waarom', en 'zou een pc met meer geheugenbandbreedte ook zorgen voor een veel sneller eindresultaat' zouden een poging waard zijn om te stellen.

Ik zou het meer toespitsen: "Wat is in standaard gebruik de performance factor die bottlenecking is?"

Daar komt bij dat zijn gebruik mogelijk niet geheel standaard is, dus je zou ze ook kunnen vragen hoe het makkelijkst te zien IRL wat de beperkende factor is.

Het rekenwerk van het programma is vrij rechttoe-rechtaan C-programmering zonder interactie met de rest van de pc. Het programma draait ook op UNIX-systemen. Het is een optie om daar naar te kijken, al denk ik niet dat hij daar verstand van heeft of mensen heeft die daar verstand van hebben. Ik weet er niets van, en weet daarom ook niet of het voordelen biedt boven Windows. Het lijkt me niet aangezien het toch een kwestie van processorpower en geheugen/geheugenbandbreedte is. Maar ik kan het mis hebben.

De SMP (multi-CPU/core) scheduler verschilt nogal tussen OSsen en kan in gevallen als dit flink uitmaken. Dat gezegd, zowel die van Windows als van Linux zijn 'mature' te noemen. A priori kun je dus niet zeggen of de een beter zal werken of de ander. Je zou ook hier gewoon de vraag kunnen stellen wat in deze app doorgaans op dezelfde hardware beter presteert, Windows, Linux of (onwaarschijnlijk) andere Unixen.

Het programma gebruikt zelf ook checksums, waarmee de noodzaak van ECC kleiner wordt.

Kijk, dat scheelt. Dan nog zou ik ECC gebruiken als het enigszins kan, maar je kunt allicht een beetje riskanter zijn dan je zonder zou mogen.

Het wordt een zaak om dus wat meer te testen om te weten wat de handigste upgrade-strategie is voor nu en de toekomst. Het programma zit vol met beveiligingen, ook nog een dongle enzo, ik zal 's vragen of het mogelijk is om het op andere systemen te installeren, of dat er voor elk systeem een nieuwe code moet worden opgevraagd bij sigmasoft waardoor die mogelijkheid beperkt is.

Ik zou eerst en vooral de bottlenecks goed duidelijk krijgen. Dan kun je gaan kijken naar upgrade-strategie.

Op moment dat we weten dat een (dure) upgrade de productiviteit van deze app kan verviervoudigen, wat mogelijk de productiviteit van je kennis zou kunnen verdubbelen, klinkt het duidelijk dat er reden is om *nu* te upgraden. De vraag is alleen of je een groot deel van die verbetering kunt realiseren met een bescheidenere aanschaf. Ik ben vrijwel zeker dat dat kan

[johnkeates]

Het kan voordelen bieden om een Linux of Unix kernel gebaseerd systeem te gebruiken, om dat je desnoods zelf een kernel kan bakken die alles geoptimaliseerd heeft om die ene applicatie te draaien. Je kan ook alles wegslopen wat je niet nodig hebt. De kernel van windows kent specialisatie niet echt, dus daar zal je nooit volle hardware performance mee trekken. Probleem is dan wel dat er wat kennis nodig is om alles echt zo snel te laten werken. De schedulers zijn beiden mature, maar je kan in ieder geval bij Linux zelf kiezen welke je wil, plus je kan vrijwel zonder enige externe 'services' draaien. Geen programma's die een beetje RAM en wat context switches wegsnoepen dus. Als het dus een werkstation moet worden voor een hele specifieke applicatie, dan loont het wel om zelf de software omgeving ook op maat te maken.

[TerraGuy]

Misschien leuk om nog even te laten weten wat er van het geheel geworden is.

Uiteindelijk is er voor 3000 euro een i7 990X-systeem met non-ECC geheugen in elkaar gezet De boel is overgeklokt naar 4,8GHz met het geheugen op 1600MHz en draait stabiel rond de 40 graden C. Berekeningen die eerst 4 dagen duurde, duren nu nog maar een halve dag en worden foutloos afgeleverd. Dat is flink sneller dan hij voor elkaar kan krijgen met het aanbevolen 6-core Xeon-systeem die hij even geprobeerd heeft op z'n werk. De cache blijkt niet veel uit te maken, CPU & geheugensnelheid des te meer. Dus hij (en ik) zijn erg content met de afloop.

Nog wel apart is dat het programma nog steeds relatief weinig CPU-tijd gebruikt, en soms kickt zelfs Speedstep in tijdens de berekeningen en floept hij tussen de 1,6GHz en 4,8GHz! Laten we het maar gooien op slechte optimalisatie van de software dan en desalniettemin blij zijn met de toegenomen productiviteitsfactor voor flink minder geld.