HPE betrekt opensourceontwikkelaars bij nieuwe computerarchitectuur

Hewlett Packard Enterprise heeft een aantal tools vrijgegeven voor opensourceontwikkelaars om hen in een vroeg stadium te betrekken bij The Machine. Dit is HPE's testplatform voor een nieuwe computerarchitectuur, waarbij de nadruk op de volgende generatie geheugen ligt.

Met de tools kunnen ontwikkelaars onder andere bijdragen aan veranderingen aan Linux om dit OS beter te laten draaien op The Machine en om applicaties te maken die de voordelen van de nieuwe computerarchitectuur demonstreren, schrijft HPE. Het bedrijf doelt daarmee met name op memory-driven computing. HPE wil bij The Machine namelijk gebruik gaan maken van grote hoeveelheden geheugen dat een combinatie van werk- en opslaggeheugen vormt.

Het bedrijf maakt vier tools beschikbaar. Het gaat om een nieuwe database-engine die een groot aantal cpu-cores en non-volatiel geheugen kan benutten en een programmeermodel dat multithreaded code aanpast voor gebruik in persistent geheugen. Daarnaast heeft HPE een omgeving vrijgegeven die de architectuur van The Machine emuleert. Ten slotte is er een platform op basis van dram dat de latency en bandbreedte van toekomstige byte-addressable nvm-technologie emuleert. HPE belooft in de komende maanden nog meer tools vrij te geven en de bestaande code te verbeteren. Aan het einde van het jaar wil HPE The Machine voor het eerst publiekelijk demonstreren, waarbij code die ontwikkelaars aandragen, op het systeem gaat draaien.

HP maakte in 2014 bekend aan de nieuwe computerarchitectuur te werken. Het bedrijf neemt nieuwe technologie als basis van het systeem, zoals memristors, weerstanden met geheugen, en optische interconnects voor snelle datacommunicatie. HP schatte destijds dat het systeem op zijn vroegst in 2017 zou kunnen verschijnen, maar het zou ook pas rond 2020 kunnen worden.

Helaas!
De video die je probeert te bekijken is niet langer beschikbaar op Tweakers.net.

Reacties (39)

[MSalters]

Het is veelzeggend dat het "programmeermodel" gebaseerd is op `nvm_alloc/nvm_free'. HPE zegt wel dat het ook met C++11 threads zou moeten werken, maar de API is op C89 nivo. Als je developers nog op in de 20ste eeuw leven, dan heb je als bedrijf weinig toekomst. Zelfs de verwijzing naar C++11 is al zorgelijk, inmiddels is C++14 al uit. Tegen de tijd dat HPE hun C++11 support rond heeft is C++17 vermoedelijk ook al uitgebracht.

En het is niet also de concurrentie stil staat. Intel heeft in 2014 "DAX" (Direct Access) functionaliteit aan de Linux kernel toegevoegd. Dat werkt dus op gangbare Intel hardware, op een gangbaar OS. Als HPE daar een nieuw OS tegeonver zet, met nieuwe HPE-only hardware, met een latere introductiedatum, dan zie ik weinig reden om over te stappen.

[johnkeates]

HPE-only hard- en software gaat natuurlijk snoeihard falen. Ze kunnen alleen echt de massa bereiken als ze commodity-schaal producten kunnen leveren.

Ze hebben erg lang gedraaid op de 'wij hebben goed spul waar je als Windows gebruiker nog wel een eind mee komt zonder alles te hoeven weten'-standaard, maar daar gaan we al een tijd niet meer in mee. Of je nou Linux, BSD of Windows draait, een black-box $Brand-only combinatie gaat het niet meer worden om dat je met een minimale hoeveelheid kennis al een generic commodity tegenhanger kan maken die hetzelfde doet voor minder, of even duur is maar gewoon geen black-box onzin is.

Behalve niche markten en bestaande klanten die nu in een lock-in zitten zijn er weinig redenen om ergens vast te blijven zitten.


Wat C++11 vs 14 en C89 (en ANSI C) betreft: nieuwere versies zijn leuk, maar niet altijd 'beter'. Zo is het niet perse gebruikelijk om ook maar iets met C++ in een kernel te doen. Het helpt nergens mee en OOP is sowieso niet handig als je low-level op near-hardware niveau werkt (a.k.a. in een kernel). Het is niet dat het niet kan en niet gedaan wordt, maar dat er te veel verdwijnt in de magie van de compiler.

[Olaf van der Spek]

Het helpt nergens mee en OOP is sowieso niet handig als je low-level op near-hardware niveau werkt (a.k.a. in een kernel).

Want? Behalve exceptions, memory allocation en virtual functions lijkt C++ mij gewoon bruikbaar.
Wie heeft het trouwens over de kernel? Volgens mij gaat dit over userland code.
Sowieso is een groot deel van de kernel niet direct bezig met de hardware en is ook een groot deel best object-oriented.

[Reactie gewijzigd door Olaf van der Spek op 22 juli 2024 18:05]

[MSalters]

Exceptions? Wat is daar mis mee? Je wilt misschien een andere implementatie dan voor userland, maar zeker een kernel heeft behoefte aan error handling. Kijk eens naar het aantal goto's in de kernel als gevolg van handmatige error handling.

Memory allocation in de kernel ? Of je 't nu kmalloc of operator new noemt, feit is dat het normaal is.

OOP? Kijk eens hoe een Linux filesysteem werkt: de tabel met functies is een handmatig gebouwde vtable, zonder compiler checks of de types wel kloppen.

Nee, Linux heeft misschien een hekel aan C++, maar desondanks zit de kernel vol zaken die in C++ heel gewoon zijn.

[Olaf van der Spek]

Exceptions? Wat is daar mis mee?

Ik weet het niet precies maar ik dacht dat ze zeker in hard-real-time situaties problematisch waren.
Error handling is zeker een punt wat waarschijnlijk beter kan.

Memory allocation in de kernel ? Of je 't nu kmalloc of operator new noemt, feit is dat het normaal is.

Waar

OOP? Kijk eens hoe een Linux filesysteem werkt: de tabel met functies is een handmatig gebouwde vtable, zonder compiler checks of de types wel kloppen.

Het zijn geen void pointers toch, dacht dat C function pointers ook gechecked werden maar ik kan het mis hebben.

[Anoniem: 47102]

De kern waarom er zoveel C gebuikt wordt ipv C++ is dat C een gefineerde ABI heeft; een C applicatie kan altijd andere C code laden. In C++ is hier geen goede mogelijkheid voor.
Daarom zitten shared objects vol met extern "C" keywords, of moet er gebruik gemaakt worden van Win32 DLL's om de boel compatibel te houden.
Een andere reden dat in de kernel C++ gemeden wordt is dat free space / heap gebruik in C++ niet altijd even zichtbaar is, terwijl kernel modules bij voorkeur een statisch geheugen gebruik hebben. Strikt gezien is dit meer een issue van de STL dan van C++ zelf.

[MSalters]

Nee. ISO C heeft geen goed gedefinieerde ABI. Het enige wat goed gedefineerd is, is de source code API. Dat is standaard ISO/IEC 9899:2011.

[johnkeates]

Think again: https://news.ycombinator.com/item?id=687587

[froggie]

Edit: dit was in reactie op @Olaf van der Spek hieronder.

Met uitzondering van safety critical software en control systems zijn het aantal applicaties met hard (of strict) real-time eisen relatief zeldzaam. Het overgrote deel van de software in de wereld, inclusief soft real time applicaties kunnen prima draaien op een OS wat gebruik maakt van "luxe" features zoals OOP, exceptions, templates en een goed functionerend type system. Juist general purpose operating system kernels zoals Linux kunnen een hoop winst halen uit dit soort features door de grote diversiteit aan functionaliteit welke aangeboden dient te worden door een kernel. Wanneer een compiler dingen als een vtable en exceptional flow control voor error handling voor je regelt kun je je als programmeur richten op het zo eenvoudig mogelijk houden van je ontwerp.

Wat betreft strict real-time en exceptions. De exception handling an sich is niet het problem. Waar het vaak botst is dat strict real-time software ook correct dient te zijn en exceptions maken het soms erg hard om de flow control van een stuk software te kunnen begrijpen. Daarbij komt dat de wat oudere implementaties vaak onnodig langzaam waren, wat er voor heeft gezorgd dat het als feature niet toegestaan wordt binnen projecten. Maar zoals met al deze tools en features; ze kunnen bijzonder nuttig zijn, zolang programmeurs de discipline hebben om ze op de juist plaats en op een goede manier toe te passen.

[Reactie gewijzigd door froggie op 22 juli 2024 18:05]

[Cowamundo]

Is dit een systeem wat moet gaan concurreren met de huidige consumenten x86 en x64 of is dit voor een specifieke bedrijfstak of doeleinden?

[Anoniem: 148406]

HPE is op bedrijven gefocust... En ik denk niet dat ze al die moeite aan het doen zijn om de stervende desktop markt op te gaan...

[Ducksy88]

Kijk het filmpje ff

[The Zep Man]

Er zit wat bullshit bingo in het filmpje dat zorgwekkend blijft: "cloud", "big data", "learning from the past to predict the future" en "for everyone". Het staat vast dat het er gaat komen, maar tegen welke prijs?

Het is echt een marketingpraatje. Zie bijvoorbeeld ook vanaf 1:37, een deel van het vliegtuigmaatschappij voorbeeld:

Virtually eliminating unpleasant surprises and standing in line.

Virtueel elimineren is niet elimineren. Bij mij komen onplezierige verrassingen en het wachten in de rij niet door computers, maar door mensen die slecht zijn in het zich voorbereiden op en het volgen van procedures in combinatie met slecht uitgewerkte procedures. Een computer gaat daar niet veel aan veranderen, en de oplossing moet niet altijd gezocht worden in de techniek.

Neem als voorbeeld het inchecken van bagage op het vliegveld. Zelf (ik meet het) heb ik altijd minder dan 30 seconden nodig om mijn koffer in te checken. Ik begrijp dat er mensen zijn die het lastiger hebben met inchecken wegens legitieme redenen (iets heeft bijvoorbeeld extra procedures nodig, of een niet-standaard document moet gecontroleerd worden) of om domme redenen (mensen meten en wegen niet zelf hun te zware koffers voor het inchecken). Maar waarom moet ik meer last hebben van die mensen en een grotere kans dat ik mijn vlucht mis dan andersom?

Dat kan je veel efficiënter maken door procedures. Een grof voorbeeld: doe je langer over het inchecken dan (bijvoorbeeld) een minuut, dan wordt je doorgeschoven naar een tweede wachtrij voor mensen die elk langer dan een minuut nodig hadden om in te checken. Doe je het binnen een minuut, dan ben je klaar en hoef je minder lang te wachten.

Zelfs met een enkele wachtrij en meerdere balies (waarbij de eerste in de wachtrij geholpen wordt door de eerste vrije balie) heb ik vaak genoeg gezien dat alle balies 'bezet' zijn door reizigers die veel tijd nodig hebben voor hun zaken. Met het genoemde voorstel hoeven de vlotte reizigers niet het slachtoffer te worden van de tijd die zwaar beladen reizigers nodig hebben.

Om een lang verhaal kort te maken: computers kunnen assisteren om doelen te bereiken, maar ze zijn niet het doel an sich. Te vaak wordt de oplossing gezocht in meer hardware en communicatie (zo ook in dit filmpje: meer geheugen, meer data processing!), terwijl het vaak organisatorisch pragmatischer en goedkoper kan.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 18:05]

[Hipska]

Het filmpje leek mij ook meer van een random Kickstarter project gehaald te zijn. Dit is toch HP en professioneel bedoeld en niet als grap mag ik hopen.

[Anoniem: 288526]

"Virtually eliminating unpleasant surprises and standing in line."

Virtueel elimineren is niet elimineren.

Virtually betekent hier "zo goed als geheel" en niet virtueel

[Vayra]

Ja, dan is het toch niet volledig geelimineerd?

Elimineren is altijd volledig en niet gedeeltelijk of 'bijna', dan is het namelijk gewoon verminderen.

[Reactie gewijzigd door Vayra op 22 juli 2024 18:05]

[Anoniem: 288526]

Nee hoor, je kunt ook van het gehele proces een deel elimineren.
1) Afschaffen 2) Buiten werking stellen 3) Doden 4) Liquideren 5) Opdoeken 6) Uitdrijven van geesten 7) Uit de weg ruimen Uitmaken 9) Uitstoten 10) Uitschakelen 11) Uitroeien 12) Vernietigen 13) Verwijderen 14) Wegdoen 15) Weglaten 16) Wegwerken 17) Wegcijferen 18) Wegnemen

[Reactie gewijzigd door Anoniem: 288526 op 22 juli 2024 18:05]

[Vayra]

Juist, en dat deel is dan volledig weg.

Tekstbegrip...

[Anoniem: 288526]

Inderdaad tekstbegrip, bij elimineren hoeft er geen sprake te zijn van het geheel verwijderen van een proces. Bij het verwijderen van een onderdeel van het proces heet dat ook gewoon elimineren.

"To eliminate all unnecesary parts of a process"

Does deduction rings a bell?

[Vayra]

Juist, en dat deel is dan volledig weg.

Tekstbegrip. Nogmaals

[Anoniem: 288526]

En wat is nu je punt????

jij zegt: "Elimineren is altijd volledig en niet gedeeltelijk of 'bijna', dan is het namelijk gewoon verminderen."

En ik zeg: "bij elimineren hoeft er geen sprake te zijn van het geheel verwijderen van een proces. Bij het verwijderen van een onderdeel van het proces heet dat ook gewoon elimineren."

Jij vindt dus dat er zou moeten staan: "Reduce unpleasant surprises and standing in line."

Deze zin is minder krachtig, en zegt veel minder immers 1% is ook al verminderen. Virtually eliminate zegt meer, namelijk zo goed als geheel. Dat jij vindt dat dat incorrect is omdat elimineren letterlijk betekent dat iets geheel weg is wil niet zeggen dat de combinatie virtually (zo goed als) en eliminate (verwijderen) fout is.

Wat ze bedoelen met die zin is: Zo goed als geheel helemaal vewijderd maar dus net niet (marge).

In jouw manier van denken mag bijvoorbeeld "zo goed als een volle tank" ook niet want vol betekent 100% en niet 98%

Zo, balletje weer terug naar jou... TEKSTBEGRIP!!!

[cpt Iglo]

Dus mensen op het vliegveld moeten eerst prutsen
dan worden ze doorgeschoven en beginnen ze weer op 0 alleen zodat ikke ikke snel door kan lopen?

wat veel beter werkt is informatievoorziening vooraf goed en compleet maken zodat het prutsen überhaupt wordt voorkomen.

[supersnathan94]

Die informatievoorziening is er al. Je krijgt bij het boeken van een vlucht vaak netjes uitgelegd aan welke eisen bagage moet voldoen. Je moet immers vaak ook inkopen op basis van gewicht.

[Tazzios]

Je incheck voorbeeld komt mij over als; "iedereen die niet 130 rijd waar je 130 mag moet rechts rijden zodat ik 130 kan rijden". Voor jou persoonlijk een verbetering voor het geheel totaal niet.

[supersnathan94]

Zeer zeker wel. De algehele doorstroming is dan veel hoger. Minder op de rem trappen en dus minder files tot gevolg. Inhalen doe je alleen "plankgas" en niet met 0.5KM/h sneller dan de auto die je inhaalt dan heeft iedereen er baat bij.

[kidde]

Nu is het op het vliegveld in uw snelweg-analogie zo dat vrachtwagens op alle banen rijden, en tractoren mogen er ook op. Persoonlijk ben ik toch best blij als vrachtwagens zoveel mogelijk rechts rijden.

De gemiddelde wachttijd (voor -iedereen- in de rij) daalt zelfs als de snelle mensen eerst gaan.

Bv Anton gaat eerst heeft 5 minuten nodig, daarna Bernd 1 minuut, Anton wacht 5 minuten Bernd 6 gemiddeld 5,5. Bernd gaat eerst dan Anton, Bernd wacht nu 1 minuut Anton 6, gemiddeld 3,5 minuten; winst voor de hele maatschappij!

[Anoniem: 138895]

Alleen bestaat de wereld voornamelijk uit mensen op vmbo niveau met beperkte inzichten voor wie al deze optimalisaties die je voorstelt te ingewikkeld is en alle regels alleen maar verwarring en daardoor juist vertragend werkt.

We zijn niet allemaal vlotte yuppies of tweaker nerds die hun hersenen hebben getraind op computer games en met 150 door het verkeer kunnen scheuren en toch gevoel houden van totale controle, terwijl oma voor het eerst in jaren weer de bebouwde kom verlaat en de snelweg oprijdt. De meeste mensen vliegen niet zo vaak en dus is het vliegveld een hele ervaring waar je door de drukte aan mensen en informatie niet weet waar je het moet zoeken, met duizenden opties waar je extra voor moet betalen.

Oplossingen moeten worden gezocht in de meest eenvoudige en intuïtieve hoek. Iemand die je koffers aanneemt, al je vragen beantwoordt en je brengt waar je moet zijn. Of dit humanoid robots in die je bij incheckbalie op een zelf navigerend autootje plaatst en je door security tot aan je gate rijdt en ondertussen al je koffers scant, of iets anders. Maar minder verantwoordelijkheid en eisen stellen aan mensen en meer vanzelfsprekendheid in de omgeving.

Bovendien kun je op schiphol al zelf je koffers inchecken en jezelf thuis online boardingpass uitprinten, en betalen voor priority boarding en business class. De meeste vertraging heb ik vaak door beveiliging, ellendig lange rijen mensen en een beveiliger met vmbo opleiding die uit zijn neus zit te eten bij de rontgenscanner of met zijn collega's zit te kletsen.

[vix-ducis]

Ik dacht dat HP vorig jaar aangekondigd had dat ze 'until further notice' gingen stoppen met de ontwikkeling van de memristors?

[kdekker]

De naam is niet echt onderscheidend 'The Machine'. Niet bijster origineel. Of getuigd van over-optimisme over de mogelijkheden? Dat "The' is nu niet echt bescheiden

[xmenno]

http://www.wired.com/2015...isco-dell-emc-ibm-oracle/
"Oh, sure, they’ll shuffle along for some time. They’ll sell some stuff. They’ll make some money. They’ll command some headlines. They may even do some new things. But as tech giants, they’re dead."

De innovatie komt uit andere hoek.
http://www.theregister.co...n_be_yours_for_christmas/

[ro8in]

HP probeert hier de basis van computing opnieuw uit te vinden, dat zal alleen heel en heel lastig worden om dit doorgezet te krijgen.

Veel dingen die wij vandaag de dag doen gaan op lagen en lagen van ontwikkeling van dingen waarop onze tools nu draaien. Websites draaien op PHP, PHP draait weer op een webserver, webserver draait weer op een OS and so on... Dan niet te spreken over alle modules etc. Al deze lagen zijn vaak ook over de jaren heen geevolueerd tot steeds completer en uitgebreider. Wil the machine een bruikbaar iets worden dan zal deze ontwikkeling van al deze lagen dus weer opnieuw moeten gebeuren. Simpelweg porten zal niet gaan door de compleet andere manier van werken op deze nieuwe computer.

Ik ben natuurlijk all for it and het klopt dat inmiddels een hoop dingen aan de architectuur wel beter kunnen, maar om de wereld uit te dagen om even alles opnieuw te gaan doen wat wij tot nu toe bereikt hebben.. Dat is een hele zware opgave.

[xmenno]

En daarom hebben ze zo iets van als we dat nou door een community laten doen, dat klinkt lekker makkelijk, zo ging het met Linux ook.

[Katanatje]

Recent heb ik nog een presentatie van HPe bijgewoond over The Machine. Ze zeggen dat het een 'big bet for the company' is. Combinatie van memristors en fotonica, eventjes de hele architectuur op z'n kop zetten . Ik hoop dat ze slagen!

[Anoniem: 304381]

Als dit gaat werken dan vereenvoudigd dat veel software/algoritmes en zullen nieuwe algoritmes ook interessant worden, die nu niet interssant zijn vanwege geheugen bottlenecks !

[Hipska]

Jij blijkbaar

[AmigaWolf]

Als dat een van die topdagen uit je bestaan was is je leven wel erg zaai, wow.

Verders eigenlijk nooit last van problemen op mijn Game PC's, niet met XP niet met Vista niet met Win7,8, en nu 10, en als ik een keer wat had loste ik die op en kon ik weer heel lang zonder enkele problemen weer alles doen.