Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 45 reacties
Bron: GamePC

GamePC verrast ons vandaag met twee primeurs. De eerste is de bevestiging dat Windows XP 64-bits Edition is uitgerust met de ondersteuning voor Non Unified Memory Access (NUMA). NUMA is vernoemd naar het feit dat de geheugenregionen in een NUMA-systeem met verschillende snelheden toegankelijk zijn, bijvoorbeeld omdat een geheugendeel zich op een andere fysieke bus bevindt dan de processor die dit gebied wil benaderen. Deze architectuur was tot voor kort voorbehouden, met enkele uitzonderingen, aan systemen die niet gebruik maakten van de x86-architectuur.

Het was dan ook niet nodig voor Microsoft om de verschillende Windows NT-versies te voorzien van NUMA-ondersteuning. Maar met de komst van de AMD Opteron-processor is dat veranderd. In een multiprocessor systeem dat gebruik maakt van de Opteron kan iedere cpu namelijk over zijn eigen geheugen beschikken dat ook door de andere cpu's kan worden aangesproken: een NUMA-architectuur dus. Reden genoeg dus voor Microsoft om naast 64-bits ondersteuning, ook ondersteuning voor NUMA in te bouwen in de Windows XP 64-bits Edition en de 32- en 64-bits versie van Windows 2003 Server Enterprise Edition.

De tweede primeur is het benchmarken van de NUMA-architectuur zelf. Naar ons weten is GamePC namelijk de eerste die een flink aantal testen heeft gedraaid om het verschil in snelheid te meten tussen niet-NUMA en NUMA. Hiervoor hebben ze een Tyan Thunder K8W voorzien van twee Opteron 248-processors waarop ze twee verschillende combinaties van geheugenmodules hebben gestoken. In de eerste combinatie worden alle geheugenmodules aan een processor gekoppeld en in de twee configuratie worden de modules over de verschillende processors verdeeld. Dit leverde de volgende verschillende combinaties op:

TotaalDIMM'sChannelsNUMA
1GB2 x 512MBdualnee
1GB2 x 512MBsingleja
2GB4 x 512MBdualnee
2GB4 x 512MBdualja

Met behulp van SiSoft Sandra 2004 SP1, draaiende onder de beta-versie van Windows XP 64-bits Edition werd gemeten hoe snel het geheugen kan worden benaderd. Hieruit blijkt dat een systeem met 2GB aan geheugen in een dual-channel en NUMA configuratie, maar liefst 10GB aan data per seconde kan verplaatsen. Dit is echter niet terug te vinden in benchmarks met Unreal Tournament 2004 en Adobe Photoshop. Dit komt waarschijnlijk omdat deze applicaties geen baat hebben van de grotere bandbreedte. In het geval van Unreal is het zelfs zo dat dual-channel NUMA iets langzamer is dan dual-channel niet-NUMA. Iets dat verklaard kan worden door het feit dat de latentie van geheugen dat via een NUMA-architectuur wordt aangesproken iets hoger is dan bij een niet-NUMA-architectuur. GamePC heeft hierna ook nog een flink aantal testen gedraaid met een hoop verschillende configuraties, variërend van single-channel zonder NUMA met maar 512MB aan geheugen tot dual-channel met NUMA en 6GB aan geheugen. Deze testen geven nagenoeg hetzelfde resultaat. De conclusie is dan ook positief en GamePC voorspelt zelfs dat er grote kans is dat Intel in de toekomst ook met processors uit zal komen die een geïntegreerde geheugencontroller hebben.


Opteron dual-channel NUMA
Opteron dual-channel niet-NUMA
NUMA-architectuur
geen NUMA-architectuur

* Update

Naar aanleiding van dit artikel heeft Tweakers.net lezer JumpStart ook enkele testen gedraaid op een dual-Opteron 244 systeem waarover hij de beschikking heeft, waarvoor onze dank groot is. Dit systeem heeft als basis een Tyan Thunder K8W moederbord waarop elke processor is uitgerust met twee 512 MB PC333 ECC registered DDR SDRAM-modules (CAS 2,5-3-3-3 dual-channel). Op deze machine draait de 32-bits versie van Windows 2003 Server Enterprise Edition met NUMA ondersteuning. Op de eerste screenshot kunnen we zien hoe snel het geheugen is in de geheugenbenchmark van SiSoftware Sandra 2004 (Win32 x86) Version 2004.10.9.89, als de ondersteuning voor NUMA is uitgeschakeld, terwijl we op de tweede screenschot kunnen zien hoe snel het geheugen is als NUMA aan staat. De resultaten bevestigen trouwens de resultaten van GamePC:

Dual Opteron 244 - Geheugenbandbreedte (MB/s)
Met NUMAInt 8244
Met NUMAFloat 8155
Zonder NUMAInt 3599
Zonder NUMAFloat 3853

Lees meer over

Gerelateerde content

Alle gerelateerde content (30)
Moderatie-faq Wijzig weergave

Reacties (45)

De conclusie is dan ook positief en GamePC voorspelt zelfs dat er grote kans is dat Intel in de toekomst ook met processors uit zal komen die een geïntegreerde geheugencontroller hebben.
Als dat zo is dan is Intel niet alleen AMD toch 'een beetje aan het volgen' in de 64bits markt, maar ook het integreren van de core.

Dit moet toch een zeer positief beeld afgeven voor AMD, dat ze trendsetter zijn, en dat de nu grootste, allergrootste cpu bakker AMD na volgt.
Dat betekent ook dat je in de spotlight staat, dat je te boeken gaat staan of al staat als innoverend. En dat spreekt bedrijven heel erg aan. Als ze dan daarom heen ook nog een reclame campagne kunnen plaatsen (als ze er voldoende geld voor zouden hebben) dan zou het helemaal geweldig zijn.
Heb jij ergens gezien dat de door intel geintroduceerde 64bits extenties van AMD zijn? Nee... Dus voor 99% van de consumenten zijn die door Intel uitgevonden, zij weten simpelweg niet beter. En als Intel deze strategie gaat volgen, zullen ze ook zeker niet bekend maken dat deze van AMD geleend is.

Daarnaast is AMD volgens mij niet de eerste die de geheugencontroller in de CPU integreerd.
AMD zal misschien niet de eerste zijn, maar AMD en Intel zijn wel de grootste spelers op de Windows Desktop afzet markt. Daar heb ik het dan over. En AMD en Intel zijn de enigste bekende bedrijven... al kennen veel mensen AMD nog nieteens :(

maja de 64bits extensies van Intel zijn niet 100% hetzelfde als die van AMD maar ze zijn wel degelijk compatible! Daar volgen ze AMD dus gewoon in.. ze riepen eerst dat het niet nodig was, en ze volgen nu wel eerder dan geplant.
Laat ik nog eens een gedurfde uitspraak doen. IBM en AMD werken al een tijdje erg intensief samen.
Nou en dan? Als twee bedrijven op R&D-vlak gaan samenwerken dan levert dit nu eenmaal meer en sneller resultaten op. Daar kan je toch niet tegen zijn.
Indien je je lijstje aan wil vullen: AMD was ook de drijvende kracht achter Hyptertransport (dit heb ik me toch laten vertellen). Deze standaard levert toch ook veel prestatiewinst op!
Natuurlijk weet de "gewone mens" dit niet, maar deze weten ook niet dat Intel SSE2 heeft uitgevonden. AMD heeft dit immers ook op haar Procs.

Ik denk trouwens niet dat IBM gewoon zegt:"We zullen AMD eens wat vooruithelpen." AMD zal ook zeker bijdragen tot de research. Beide partijen zullen zeker een even groot aandeel hebben in de uitvindingen. IBM zal zich niet zomaar int zak laten zetten :Y).
Dat is niet helemaal waar. Ik heb van AMD tv reclames gezien waarin word gezegd dat het de verniewde 64 bit extensies voor servers heeft. Men zou het dus kunnen weten. Als je een beetje interresse heb hiervoor dan zou het dus kunnen want het er is wel reclame mee gemaakt.

Maar natuurlijk was dit nou ook niet bij een of andere super goed bekeken proggramma (discovery denk ik zelfs) dus de massa kijkt daar niet naar en weet dat dus.

Maar er zou een iets grotere groep dan alleen tweakers het kunnen weten. Alleen is het dan nog maar de vraag of ze weten wat 64-bit extensies zijn.
Hmm 64-bit, geintegreerde geheugen controller, numa innoverend.
Hmm intel, sgi, sun en ibm zijn al jaren met sommigen en ibm met alle technologieen bezig. IBM is ook erg onbekend en een kleintje, net als sgi en sun.
Laat ik nog eens een gedurfde uitspraak doen. IBM en AMD werken al een tijdje erg intensief samen. Ik heb het gevoel dat dat er wel iets mee te maken heeft dat AMD, wat toch tov van ibm wel een kleintje is ineens zo "innoverend" kan zijn. IBM helpt amd bijvoorbeeld ook met lithografie en pipeline design, dus waarom niet met numa en geheugencontroller design.
Blind staren op x86 en windows schiet niet zo op. Er zijn zat mensen die weten wat een mac is.
Innoverend van amd is de 64-bits extensies op x86, da's al.
Ik denk trouwens niet dat IBM gewoon zegt:"We zullen AMD eens wat vooruithelpen." AMD zal ook zeker bijdragen tot de research
AMD is klant bij IBM voor de lithografie en het logic design. En wie zegt dat het alleen op die vlakken zo is. Ik zeg niet dat daarmee AMD geen bijdragen levert aan de R&D. Ik vermoed alleen dat de verhoudingen wel naar een bepaalde kant neigen en dat is niet die van AMD. Het zal niet voor niets zijn dat IBM zoveel grote klanten naar zich toetrekt, zoals apple van motorola, Microsoft. Sony en Nintendo hadden ze al en daar doen ze dus ook specialistisch werk voor. IBM zal ook niet voor niets de meeste patenten per jaar krijgen toebedeeld in de computerwereld. Ik begin een beetje een fanboy te klinken....Maar goed ik ben dan ook een statement aan het maken :)
Als dat zo is dan is Intel niet alleen AMD toch 'een beetje aan het volgen' in de 64bits markt, maar ook het integreren van de core.

Dit moet toch een zeer positief beeld afgeven voor AMD, dat ze trendsetter zijn, en dat de nu grootste, allergrootste cpu bakker AMD na volgt.
Het concept van een on-die geheugencontroller is echt niet bedacht door AMD hoor. HP had het in 1991 al op de PA-7100LC, en waarschijnlijk zijn er nog wel oudere voorbeelden te vinden. Ook is het niet zo dat AMD degene is die het nieuw leven in heeft geblazen of iets dergelijks. Transmeta heeft het in alle Crusoë / Efficeon processors sinds de eerste TM5600 uit 2000, Sun sinds de UltraSPARC IIe (ook uit 2000), HP in de Alpha EV7, IBM in de Power5 (nog niet uit maar al wel vele jaren 'under construction'), etc.

Er is dus meer dan Intel en AMD in deze wereld. Dat Intel op sommige vlakken wat conservatiever is dan AMD zal ik niet ontkennen, maar om AMD daarom nu meteen te gaan bestempelen als de grote trendsetter in processorland gaat wel erg ver.
Het concept van een on-die geheugencontroller is echt niet bedacht door AMD hoor.
Wat misschien ook een interessant weetje is is dat een vorm van NUMA ook al veel eerder toegepast is in de Amiga (1985). Er werd een verschil gemaakt tussen Chip- en Fast-RAM (en tussenvormen zoals Ranger) die op verschillende modellen via verschillende bussen toegankelijk waren: via de processorbus (geheugen geïntegreerd op het moederbord, op losse kaarten in 'trapdoor' slot, op externe HD controllers op hybride Zorro/processor extensieslot, geheugen op losse processorkaarten) of via de Zorro of video bus (PCMCIA kaarten, losse Zorro geheugenkaarten of op SCSI controllers, zelfs grafisch geheugen van videokaarten).

De verschillende typen geheugen werd automatisch ingebonden in het systeem met verschillende priorities zodat het snelste geheugen het eerst kon worden gebruikt, bepaalde soorten konden softwarematig uitgeschakeld worden (nofastmem), voorrang gegeven (fastmemfirst), je kon zelfs de priorities veranderen (ChangeMemPri op Aminet),software kon zelf bepalen welk soort geheugen het wilde gebruiken of kon worden omgeleid via utilities zoals MCP (force fast), een ongelofelijk flexibel systeem.
Ja oke heb je gelijk in.

Maar als je ziet dat het platform toch vrij veel veranderd is. De desktop markt bestond gewoon meerendeel uit Intel en een beetje AMD.

DIe cpu's zaten al jaren op x86-32. AMD heeft gewoon de stap naar 64bits gezet, wat als vrij groote stap mag worden gezien vind ik. Ook durven ze het nu aan de mem controller op de cpu naast de die te bouwen.

Oke trendsetter in cpu land gaat te ver, maar ze hebben toch een paar grote stappen gezet met de K8 series(vind ik dan, in de desktop markt).

ps. ik bedoelde eik ook alleen trendsetter op gebied van mem controller en x86-64, niet dat ze al jaren bezig zijn natuurlijk met vooruit lopen al hebben ze hun dingen gehad :)
Intel moet wel, aangezien Windows XP een enorm grote afzetmarkt heeft en Microsoft geen aparte Intel versie meer gaat bouwen. Dus Intel moet wel mee met AMD in dit geval... tenminste, het lijkt me wel zo slim van ze ;)
Ze riepen in het begin dat de markt er niet klaar voor was, en dat het niet nodig was.

Nu gaan ze echter sneller als geplant eerst mee, daar gaat het mij om.

Als ze vanaf het begin hadden geroepen ja AMD, goed plan! Maar dat hebben ze natuurlijk inet gedaan, AMD heeft het toch doorgezet en Intel gaat ondanks hun negatieve uitlatingen er nu toch in mee!
Non Unified Memory Access
moet zijn Non-Uniform Memory Access.

Zou niet weten wat ik me voor moet stellen bij
Non Unified
. Misschien een mix van DDR en Rambus of DDR2 en EDO? :+

\[edit:]

@Ralph Smeets:

Google geeft 45 hits bij unified en 13.000 hits bij uniform. Bovendien krijg ik bij Fujitsu-Siemens ook veel meer hits bij uniform dan bij unified: 11 om 2. Dus unified is gewoon fout volgens mij.
Ik quote uit het artikel van GamePC:
which in turn paves the way for NUMA (Non-Unified Memory Access) support.
Een search met google leert ons trouwens dat Uniform veel meer gebruikt wordt dan Unified. Als je trouwens naar de betekenis van zowel Uniform als Unified kijkt, en naar de architectuur zelf, dan kunnen beide termen gebruikt worden. Fujitsu-Siemens gebruikt bijvoorbeeld de term non unified memory access, terwijl SGI uniform gebruikt. Hert kan dus beiden.
GamePC maakt rare conclusies. NUMA heeft opzichzelf niets te maken met het wel of niet hebben van een eigen memory controller.
De door tweakers aangeduide uitzondering is daar een heel mooi voorbeeld van. Daar is het 'gewoon' via de chipset gedaan.

Verder natuurlijk wel een beetje onnozel om NUMA te gaan testen met applicaties als UT en Photoshop. Weet je bij voorbaat dat je niets te zien krijgt.
Die Sisoft benchmark is leuk om te zien, maar geeft alleen maar een super best case. Het levert nul komma nul informatie over hoe effectief NUMA zal gaan werken.

Die primeur krijgt wat dat betreft van mij een "-1 first post" moderatie, aangezien ze welbeschouwd geen enkele informatie leveren.

De echte vraag is in hoeverre OS én applicatie er in de praktijk ook voor kunnen zorgen dat cpu's bij hun eigen geheugen kunnen blijven, en slechts weinig bij andermans moeten lenen?
Multi cpu, multi-threading, hyper-threading, e.d. zien er theoretisch ook altijd prachtig uit, maar de praktijk is weerbarstig...
het inderdaad well interessant om er achter te komen of microsoft inderdaad een numa design is nagaan streven, of eerder een skuma (sorta kinda uma).

Numa is over het algemeen niet moeilijk te implementeren, maar er komt wel veel bij kijken. Het feit dat unreal wat langzamer werkt onder de "numa" implementatie, geeft al aan dat de numa implementatie van windows ofwel langzamer is, ofwel een skuma implementatie is.
Moet Intel wel eerst ff afstappen van de bus die ze nu gebruiken sinds, ik geloof, de Pentium Pro.

AMD gebruikt een point-2-point verbinding van processor naar geheugen (iedere cpu een eigen verbinding naar het geheugen) TOV Intel bus (weet naam ff niet meer), wat een gesharede bus is waardoor als 2 CPU's tegelijk het geheugen willen benaderen ze de bandbreedte moeten delen.

Dit is ook een van de redenen dat Intel multi-proc systemen minder goed schalen.
Vind het ook het goed recht van AMD om eindelijk als innovatief beschouwd te worden; na 40 jaar Intel breekt nu wellicht tóch de tijd aan voor AMD. Zij hebben altijd tegen Intel moeten aanleunen en zijn vanaf het begin (gestart enkele jaren ná Intel) al de volgers geweest.
Hoe heet die wet?

"wet van de remmende voorsprong".

Het kostte AMD 40 jaar om Intel in te lopen..

Goed gedaan AMD & Intel!

Edit: correctie, ok, bijna 35 jaar dan?
AMD is pas met de 386 begonnen met het maken van x86 chips. Voorheen maakten ze andere soorten chips. AMD vs Intel is iets van de laatste 10 jaar.
40 jaar? In welk jaar is AMD opgericht dan?
Hmm, de tijd is voor AMD zeker sneller gegaan dan voor mij dan.
2GB 4 x 512MB dual nee
2GB 4 x 512MB dual ja
Wat is het nou? Ja of nee? Of is die laatste single channel? ;) Verder eigenlijk wel jammer dat NUMA (nog) geen dual channel ondersteund... Ik vraag me eigenlijk af waarom dat dat zo is... :(
Ja en nee staat voor NUMA... wel of geen NUMA, maar alletwee dual channel
die laatste is 4 * 512 MB en dat 2x op elkaar zodat een suspensie onstaat van de geeumuleerde waardes van de 64 bits extensie }:O
Ondanks deze twee primeurs heeft GamePC voor mij een beetje afgedaan.

Eerst hadden ze nog goede benchmarks zoals Maya rendertest.

Nu ook weer van die domme benchmarks. Allemaal van die populariteit benchmarks zoals unreal tournament 2004.

Gebruik dan programma's waar geheugen echt veel uitmaakt. Zoals 3D rendering.
Sorry hoor,maar het is niet voor niets GAMEPC,de naam zegt het al, die het heeft gedaan,dus is het logisch dat ze ook games als benchmark hebben gebruikt
het gaat hier wel om een dual opteron systeem, niet echt bepaald een standaard game bak.
GamePC maakt normaal gesproken best wel aardige workstation reviews. Het is de enige site die op regelmatige basis 2-way processors en dual processor moederborden bespreekt. Het is jammer dat er voor deze review zulke slechte benchmarks werden gekozen. NUMA-optimalisaties hebben vanzelfsprekend weinig zin als er geen sprake is van hoge gelijktijdige belasting van beide processors, wat bij Photoshop vaak niet het geval is en bij Unreal Tournament al helemaal niet zal voorkomen.
Maakt unreal tournament eigenlijk wel gebruik van smp ? Als dat niet zo is... dan houd windows hem zelf het process op 1 processor ?
Ik zou wel eens een Linux benchmark willen zien met en zonder NUMA.

De vraag is dus of het verschil komt door Windows of dat NUMA goed is geinplementeerd

Het is algemeen bekend dat windows nou niet echt lekker schaalt, in iedergeval niet zo linear als de 2.6 kernel
Ik weet dat op een 416 CPU Itanium 2 linux met NUMA ongeveer zo'n 1.76 TFLOPS draait (2.2 peak)... maar ja, ik denk niet dat de beheerders daarvan WindowsXP willen installeren om te vergelijken :)
Als ik het complete artikel bekijkt, heb ik meer het gevoel dat UT de boosdoener is met raar varierende benchmark resultaten, dan dat Windows een slechte NUMA implementatie heeft.

Ik zou de standaard deviatie van die meting wel eens willen zien....
Ik hoop niet dat dit noob overkomt....
Is het nodig voor een programma om op NUMA ingesteld te zijn, zoals het bij voorbeeld nodig is om voor multi processor geschreven te zijn :?
3DS-Max bij voorbeeld is geschreven om op een multi-processor platform te draaien en heeft daar dan ook bijzonder veel baat bij. Geldt dit ook voor het UMA/NUMA-verhaal?

<nag>
het is Non-Unified Memory Access (met dubbel s, dus)
</nag>
ja, en nee.
Een programma dat veel geheugen nodig heeft, kan mte NUMA meer geheugen aanspreken, en daarom sneller werken. Het geheugen achter de andere processoren is dan wel langzamer, maar nog altijd een stuk sneller dan diskswappen. dus als er geen optimalisatie plaats vindt, kan het al een stuk winst opleveren.

Maar een programma dat goed multi-threaded is geschreven haalt nog veel meer voordeel uit 2 (of meer) processoren + numa. Juist met meerdere threads is het handig dat een processor een tussen resultaat direct uit het RAM van de andere processor kan lezen. Tijdens het wegschrijven van gegevens is alleen het geheugen van de processor die het wegschijft bezet, de rest kan volledig doorrekenen, het ophalen van deze gegevens merkt de "wegschrijvende" processor weer niet, omdat alleen de geheugencontroller daarmee bezig is. In feite komt het er dus op neer dat er meer "dingen" paralel gedaan kunnen worden. Kortom, juist met multi-threaded en multi-tasking operaties is er veel winst te behalen. Omdat numa alleen in een multi processor omgeving gebruikt kan worden, zal de gebruikte software meestal sowieso al wel multithreaded zijn. Dus hier is ook geen probleem.

Omdat bij de Opteron iedere processor meerder hypertransport kanalen heeft, kan het hele numa gebeuren snel afgehandeld worden zonder dat de boel dichtslipt. Dus daarom is er voor deze processor juist veel winst te behalen. Een Xeon met (één) traditionele FSB(is dus nog neit numa geschikt) maar kan hier voorlopig minder winst boeken. De Xeon zal dus de traditionele FSB ook overboord moeten gooien, om goed van numa te kunnen profiteren, en dus beter te schalen met meerdere processoren.
Je maakt een denkfout. Met NUMA kun je niet meer geheugen gebruiken. Dat wordt immers gewoonweg bepaald door de adres ruimte van de geheugen bus. Dus de kwestie is niet 2GB zonder NUMA t.o.v. 4GB met NUMA, maar 4GB voor beiden gevallen.

De kwestie is dus niet de hoeveelheid, maar via welke weg je naar je geheugen gaat, en hoe je dat verdeelt.

In principe is 1 gezamelijk snel toegankelijk geheugen ideaal. Probleem is dat het fysiek onmogelijk wordt om dat bij meerdere cpu's te realiseren, omdat de weglengte van cpu naar ram te groot wordt.
En dan biedt NUMA een uitweg. Je splitst je geheugen in stukken, en geeft iedere cpu een fysiek kort, en daardoor snelle toegang er naar toe. Verder is er een extra geheugen pad, om bij de andere cpu ook in de ram te kijken, maar dat is dus wel een stukkie langzamer. Zodoende kunnen alle cpu's dus bij het gehele geheugen, en is er een gedeelte waar ze op volle snelheid bij kunnen.

De truuk wordt nu om te zorgen dat te zorgen dat iedere cpu zoveel mogelijk met zijn eigen geheugen kan werken, en niet bij de buren hoeft te kijken.

Bij het draaien van meerdere applicaties is dat niet zo moeilijk. Je zet het geheugen van de applicatie 'gewoon' bij de cpu die de applicatie ook uitvoert. Daar kan het OS zonder meer voor zorgen.

Het probleem komt bij gebruik van een enkele applicatie. Ik denk niet dat het genoeg is dat de applicatie multi-threaded is. Immers, multi-threading onderscheid zich juist van multi-tasking in de zin dat meerdere thread van hetzelfde beperkte geheugen gebied gebruik maken. En dus zitten de cpu's dan toch weer bij de buren te koekeloeren.

Lijkt me dat de applicatie dan wel degelijk NUMA aware moet zijn, om dan toch een logische opdeling van het geheugen te krijgen. Of dat het in ieder geval heel erg veel helpt wanneer de applicatie het OS daarin kan begeleiden....
ik kan mij goed voorstellen dat photoshop niet sneller wordt met NUMA ondersteuning.
Bij het multithreaded maken van de filters kunnen meerdere berekeningen tegelijk gemaakt worden waardoor de snelheid zou kunnen verdubbelen. Gezien de data waarop de bewerkingen gedaan worden hetzelde is ( de zelfde bitmap ) zal de bitmap nog steeds op 1 geheugen sim liggen, waardoor de 2e cpu alsnog niet zijn eigen geheugen sims kan gebruiken.
Door nu op deze machine 2x photoshop tegelijk op te starten, 1x op de 1e cpu met zijn eigen geheugen, en nog een keer op de 2e cpu met zijn eigen geheugen, zal dit in mijn beleving wel snelheids winst kunnen opleveren.
Er is geen reden waarom je bitmap totaal op 1 simm zou moeten liggen...
In protected mode werken applicaties immers met virtueel geheugen, waarbij fysieke en logische adressen niet gelijk hoeven te zijn. Volgens mij zou het OS gewoon de fysieke geheugen locaties kunnen opdelen zonder dat de logische indeling verandert.

Maarre... afaik maakt Photoshop geen extra threads aan om met meerdere cpu's aan dezelfde bitmap te werken. En zolang er maar 1 thread aan het werk is zal NUMA niets kunnen betekenen.
<quote>Er is geen reden waarom je bitmap totaal op 1 simm zou moeten liggen... </qoute>
idd, maar ik bedoelde te zeggen dat waar de bitmap zich ook bevindt, hij zal nooit voor beide cpu's in hun eigen sims liggen, wat voor de extra performance zou kunnen zorgen.

<quote>
Maarre... afaik maakt Photoshop geen extra threads aan om met meerdere cpu's aan dezelfde bitmap te werken. </quote>
Ik dacht eigenlijk dat Photoshop wel multithread filters aan kon, Premiere dacht ik ook/wel.

<quote>
En zolang er maar 1 thread aan het werk is zal NUMA niets kunnen betekenen</quote>
Niet helemaal waar, zonder gebruik van NUMA zou het door deze thread gebruikte geheugen niet in de dichtsbijzijnde/snel-toegankelijke sims hoeven te liggen.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True