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 , , 37 reacties
Bron: IBM

IBM maakt melding van een doorbraak op het gebied van geheugen voor in servers. Een nieuwe technologie zorgt ervoor dat er twee keer zoveel data kan worden opgeslagen in het geheugen, waarmee tevens de performance verhoogd wordt. De nieuwe IBM eServer xSeries 330 zullen worden uitgerust met deze Memory eXpansion Technology (MXT). MXT maakt gebruikt van een snel hardware algoritme om de data on-the-fly te encoderen, waardoor het minder 'ruimte' inneemt. Hieronder een gedeelte uit het artikel:

IBM logo (vrijstaand)Frequently accessed data and instructions are automatically stored close to a computer's microprocessors so they can be accessed immediately --- improving performance in memory constrained environments. Less frequently accessed data is compressed and stored in memory -- helping to increase memory capacity by a factor of two or more.

TweakerWannabe was zo attent ons hierover te tippen.

Lees meer over

Moderatie-faq Wijzig weergave

Reacties (37)

Ik denk dat het voor een OS vrij moeilijk is om te begrijpen dat de hoeveelheid geheugen variabel is, of ze moeten ook de softwarematige memorymanagement totaal gaan aanpassen.

Dat is natuurlijk voor IBM en "hun" OS'en geen probleem, maar als het ooit voor consumenten beschikbaar komt.....
Ik neem aan dat een apart stukje hardware voor de compressie zorgt (geen power van je processor nodig) en dat dit stukje hardware ervoor zorgt dat je OS niet weet dat er gecomprimeerd wordt: je doet gewoon net of het normaal geheugen is (wat dan groter lijkt dan het in werkelijkheid is). Het aparte stukje hardware zorgt ervoor dat je de normale instructies kan gebruiken en net doen of er wat meer geheugen inzit, uit dit stukje hardware komt dan ook een gewone data stream (niet variabel).

edit:
: dus geen drivers nodig, de hardware regelt het
maar deze compressie zorgt altijd voor een hogere latency welke toch liever niet gewenst is. Het liefst willen we een snel stukje geheugen met hoge doorvoersnelheid en zeer lage latencies.
dat valt op zich wel mee. Een Windows systeem maakt het niets uit of jij er een DIMMetje bij plaatst, en als het RAM vol is wordt er virtual RAM aangemaakt op de schijf, dat is ook zo variabel als maar kan, dus ik denk dat het best meevalt zolang de chipset / BIOS zich met het encoderen bezighoudt.
Nog geen hotswapable geheugen gezien voor windows. Wat hij nl. bedoeld is dat er een variabele hoeveelheid geheugen beschikbaar is tijdens een Windows sessie. Ik weet zelf ook niet of windows daar out-of-the box wel tegen kan omdat het ook windows is die beslist of virtueel geheugen aangemaakt moet worden. als de gewone memmory space op is. Maar goed sinds het geheugenmodel van de 386 zijn hier genoeg trucjes op te bedenken die met behulp van een memmory driver op te lossen zijn.
Nog geen hotswapable geheugen gezien voor windows.
Klopt. Wel eens hot-rippable geprobeerd (tijdens windows-sessie dimmetje eruit rukken), maar dat ging inderdaad niet goed (8>
De X series zijn de gewone x86 machientjes, dus geen eigen os van ibm zal de machine besturen zover bekend is. Ik weet niet hoe ze het probleem van variable data streams oplost. Maar het klinkt zeker interesant.
Ja das een goede vraag maar ik denk dat IBM voor de doorhun geleverde server waarschijnlijk een driver meesturen die dit mogenlijk maakt..want anders word het inderdaad erg lastig!
Pfff. Ik heb dit maanden geleden gesubmitted, toen werd het niet overgenomen, nu het toevallig op webwereld staat wel :?

Okay hierbij alsnog de links van met de echte uitleg:
Persbericht 26-juni-2000
Persbericht IBM 26-juni-2000!

Linux ondersteuning oktober 2001 (lees vooral het performance document):
Nieuw?

Qemm MagnaRAM ?
Dat was een softwarematige oplossing, dit is (iig deels) uitgevoerd in de hardware.
Wat ik wel zou willen weten, is of deze techniek later ook met terugwerkende kracht kan worden ge´mplementeerd op de huidige systemen.
Zij het middels een software-tooltje (ok, minder snel dan de hardwareversie omdat de cpu er eerst aan moet decoderen alvorens er weer gebruik van te kunnen maken, maar altijd nog sneller dan van-naar je HDD) danwel een hardware "iets".
((of kun je het beter houden bij een goed ingestelde cachman e.d.))
Of is dit een item om op te selecteren bij een later aan te schaffen mobo.

Lijkt mij een goede ontwikkeling, voeg dit samen met het alsmaar sneller wordende geheugen en we kunnen weer ff vooruit.
Ik hoop dat ze dit systeem standaart zullen toepassen in toekomstige chipsets..als je dit nou volledig hardware matig laat draaien en je het MXT systeem tussen het geheugen en de proc zet kun je denk ik enorme resultaten verwachten denk ik zo aangezien je 'meer geheugen' krijgt ookal is dit virtueel als je dit op de zelfde snelheid kan coderen en decoderen dan krijg je echt super goede resultaten..wat natuurlijk ook niet vergeten mag worden is het feit dat cache geheugen ook beter en efficienter beheerd wordt waardoor je ook een performance boost mag verwachten!
Ik zou dit systeem zelf bestempelen als een volledige memory beheer/beheers systeem! toppertje van IBM!
IBM maakt melding van een doorbraak op het gebied van geheugen voor in servers.
Lijkt mij logisch dat deze techniek ook voor gewone p.c.'s te gebruiken is.
Ja natuurlijk, maar het gaat hier over een server, niet over een doodnormale huis-tuin en keuken pc.

Dat de techniek straks ook voor de normale pc is weggelegd spreekt voor zich, dat is namelijk met bijna alle technieken gebeurd, eerst wordt zo'n nieuwe techniek in de serverwereld toegepast (omdat het in die markt echt om performance en stabiliteit gaat en minder over geld) en daarna vindt de techniek langzaam aan zijn weg naar de desktop.

Deze nieuwe techniek is echt nog niet geschikt voor de normale desktop pc, ten eerste zal de hardware zeer prijzig zijn en ten tweede zal de prijs/prestatie niet echt optimaal zijn.
Ik zit er niet op te wachten. geheugensnelheid is al een bottleneck en dit soort technieken werken altijd vertragend. Bovendien is geheugen niet erg duur.

Om die reden heeft toch ook niemand meer stacker op zijn harde schijf
geheugensnelheid is al een bottleneck en dit soort technieken werken altijd vertragend.
Jeeeez, geheugen MOET van jou dus een bottleneck zijn :?. Dit soort technieken zouden vertragend zijn terwijl ze de boel alleen maar sneller en efficienter maken, mogelijkheid voor vooruitgang heb je op die manier niet en dus zul je altijd ontevreden blijven. Nieuwe / betere technieken moet je juist met open armen ontvangen :(.

(Maakt niet uit, vooroordelen zijn er om weggenomen te worden ;)).
Je geheugensnelheid is inderdaad vaak de bottleneck (wis de effecten van je HD niet uit, overigens!), maar als je dan de druk verplaatst van het geheugen (waarvan de doovoersnelheid theoretisch 2x zo hoog wordt) naar je processor (die toch op je geheugen moet wachten), dan zie ik niet zoveel problemen. Het is natuurlijk afwachten hoe zoiets in het echt werkt, naast de vraag of het ook naar het PC-platform gaat.

Trouwens, texture-compressie in je 3D-kaart kun je vaak ook beter aanzetten dan uit. Min of meer hetzelfde idee.
Deze techniek is al jaren bekend, de hindernis in het verleden voor toepassing op grote schaal in PC's was een gezamelijke standaard voor de compressie. Zoals gebruikelijk konden de fabrikanten het weer niet eens worden. Later is het door de daling van de geheugenprijzen naar de achtergrond verdwenen.
Misschien dat de rest nu IBM gaat volgen.
Is het belangrijk of er een standaard is? Zolang de compressie/decompressie plaats vindt vlak voor het geheugentoegang maakt het geen moer uit welk type compressie het is.
Pas als andere chips ook direct data uit hetzelfde gecompresste geheugen willen halen moeten ze het eens zijn over de manier van compressie...
Dat zou ik ook denken maar waarom (zie hieronder) moet er dan een kernel voor aangepast worden ?
Aleen de benaming vind ik niet echt kloppen:
Memmory eXPansion
Hier word gesuggereerd dat je geheugen "groter" wordt. Noem het dan memmory commpression tech. ofzo.

en inderdaad het beheer van het geheugen moet echt zo zijn van
eerst inpakken kijken hoe groot het dan is en dat wegstouwen in het geheugen.
Hier word gesuggereerd dat je geheugen "groter" wordt. Noem het dan memmory commpression tech. ofzo.
Dus dat je geheugen eigenlijk samengedrukt wordt?
;)

Bovendien komt er in compression geen X voor, dus dat past niet in de huidige marketingmode...
"Aleen de benaming vind ik niet echt kloppen"

Allemaal marketing beste kerel.
Ik zou daarom nooit een goede marketeer of salesmens kunnen zijn. Ik kan namelijk niet goed liegen...
Ik kan me niet aan de indruk ontrekken dat het comprimeren en decomprimeren van data in het geheugen je flink wat snelheid kost...
Inderdaad, maar als je het nou volledig hardware matig doet dan is probleem ook weer opgelost!
En zoals je weet als het software matige kan kan het ook hardware matig!
encoderen
moet comprimeren zijn :).

Door het realtime te comprimeren kost het toch alleen maar power? En het lijkt mij dat je nou niet zo ontzettend veel kan comprimeren in het geheugen, hij moet het toch ongecomprimeert kunnen verwerken, normaal gesproken IN het geheugen, anders kan de pc toch nog niets??
Daar heb je absoluut gelijk in maar wat de truc is dat het hardware matig gebeurt waardoor de cpu er feitelijk niks van merkt....
de CPU stuurt de data in MXT codeert het en slaat het op....
Als de CPU de data dan weer nodigt heeft haal MXT het uit het geheugen, decoderrt het en stuurt het weer terug naar de CPU...!

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