4 ms·
The first official HPQ memristor announcement was apparently in 2008, and at that time there was conjecture it would be used both as analog and digital recordin
by sciencesama 11y ago
The first official HPQ memristor announcement was apparently in 2008, and at that time there was conjecture it would be used both as analog and digital recording media:
http://bit.ly/1fyBrWi http://bit.ly/1fyBrWi
HPQ said in 2011 that they would have memristor products within 18 months:
http://bit.ly/rtVfno http://bit.ly/rtVfno
In 2013, HP's Martin Fink was saying they would have memristor based HDD replacements by 2018. At that time, they claimed those 'early' memristors would be faster than FLASH, but not speed-competitive with RAM:
http://bit.ly/1RO05ke http://bit.ly/1RO05ke
Then in 2014, HP's Martin Fink was telling media that memristors would be faster than dram. He produced a chart showing memristors at 10 ns (no range) while dram technology ranged from 10 to 50 ns:
http://bit.ly/1fyBrWk http://bit.ly/1fyBrWk
In October of 2014, HP's Martin Fink was saying they would deliver a 'clean sheet' operating system in 'The Machine' with 157 petabytes of addressable memory and 150 compute nodes by the end of 2016:
http://bit.ly/1fyBtO6 http://bit.ly/1fyBtO6
As late as December of last year, they were promising a 'Revolutionary' new operating system in 2015.
http://bit.ly/1fyBrWo http://bit.ly/1fyBrWo
Now, there is supposed to be a show-and-tell prototype of 'The Machine' to be demonstrated sometime in 2016. It will not have memristors, and will run a slightly modified form of Linux. It is supposed to have 2,500 cpu cores and 320 TBytes of conventional RAM memory. That is about 500 times less memory than the 157 PBytes they were talking about last year. I am guessing without evidence that the processing distribution will be about 1250 Xeons with 20 cores in each, but really don't know. That amount of conventional memory suggests it won't be in a trade show, but will be in a controlled environment for invited guests, where HP can better control the message and defer all the questions:
http://bit.ly/1fyBtO6 http://bit.ly/1fyBtO6
Essentially, the point of all this is that HPQ has a long history of failing to deliver on and/or lowering the expectations of while pushing out delivery dates of announced products. There is no real reason that I can see to believe that HP Enterprise or whatever will suddenly establish the follow-through integrity that has clearly been lost in HPQ. Those fast/slow/soon/late/high yield/low yield memristors might never be available from a financial corporate descendant of HPQ.
I think there is a small fundamental flaw in the message HP is promoting about distributing their processors far apart from one another in an effort for each processor to be closer to local memory while having a seemingly contradictory flat memory model. That is that most of the tasks one would want to execute on such a machine would certainly be multithreaded. In many multithreaded tasks, parent threads need to quickly know when daughter threads have completed their tasks so that they can use these interim results to continue. The speed of light in glass fiber is typically about 2/3 that of light in a vacuum. It is reasonable to assume a typical thread process will execute (at maximum efficiency) at more than 6 billion instructions per second in the year 2020. So, let's say that a daughter thread is running 50 feet away (not physically, but as the optical cable bends) from a parent. This means that the daughter process could have executed over 450 instructions while the "thread complete" message is in transit to the parent (in addition to the overhead in more conventional architectures) and would have to wait out more than 450 additional instruction executions while waiting for the parent thread to begin issuing something new. Translated, the concept of 'The Machine' would lose its speed advantage in a programming environment where thread execution instruction counts are relatively low, such as the majority of in-memory database object manipulation.
In contrast to 'The Machine', successful architectures will, I think, increasingly move their processing cores together more akin to directions of the Nvidia Tesla, Intel Phi, and AMD FirePro, to name a few. Speculating further, massive amounts of memory may likely be arrayed spherically outward, perhaps on a 3-D radiant structure with cooling fluid [such as helium gas] running within the fingers. If each of these limbs comes with threading, contacts, and a seal system so it can be removed and replaced, then the mean-time-to-repair can be kept low.
My guess is that even though there has not been any disappointing news about 'The Machine' in over a month now, there will be a lot more as the dog-and-pony show that is supposed to occur late next year nears, and there will be more still prior to 2020
- tedunangst 11y agoIt would be deliciously ironic if the final shipping machine uses itanium processors.
- static_noise 11y agoGreat post disseminating the (likely) grossly exaggerated promises made by HP about a technology there is little evidence of! Only thing to improve is to include a numbered list of the full URLs at the end instead of or inaddition to relying on some external URL shortening service.
- semi-extrinsic 11y agoMinor nitpick: given their huge focus on memory size, they also have to care a lot about memory bandwidth. That means they want Xeons with fewer cores per CPU, since each CPU (socket) has just 4 memory channels. Furthermore, if they can get away with just 4 DIMMs per CPU, they avoid the ~20% memory throughput performance penalty from memory channel interleaving. Crunching the numbers, the thing that makes most sense is 128 GB per socket, with 10 core CPUs in that, giving 2500 CPUs, probably dual socket nodes so 1250 nodes. (I'm assuming 2,500 cores above is a typo.) So each CPU would talk to 4x 32 GB DDR4 DIMMs, which are indeed available. This is also just speculation, but I couldn't see any other options giving as good performance. Given that this speculation is correct, it's hard to see how this is much different from existing HPC hardware tailored to high-memory applications. As for what your musings on interconnect latency: I believe you are correct that you can't really run with the multithreaded paradigm once you start computing at significant physical scales. Perhaps they want to move to something MPI-like for their applications?