Slashdot Mirror
HP Unveils 'The Machine,' a New Computer Architecture
pacopico writes: HP Labs is trying to make a comeback. According to Businessweek, HP is building something called The Machine. It's a type of computer architecture that will use memristors for memory and silicon photonics for interconnects. Their plan is to ship within the next few years. As for The Machine's software, HP plans to build a new operating system to run on the novel hardware. The new computer is meant to solve a coming crisis due to limitations around DRAM and Flash. About three-quarters of HP Labs personnel are working on this project.
What's the point in running a brand new OS on it? Is HP-UX not good enough? Or the many other *NIX's? I'll put money on Linux being ported to it before it even ships to Joe Public
If you gave me a choice between a printer and a giraffe with explosive diarrhoea, i'll get my ladder and my raincoat
Finally! I'm so glad there's something to feel intrigued about in technology. I miss all the corporate labs doing amazing things.
It’s a bold strategy Cotton. Let’s see if it pays off for them.
If this doesn't work out, I can't see HP staying in business as an independent company.
The article yammers on and on about how the O/S will be built based on memory-driven I/O instead of file-system based I/O. However, IBM's i/OS (a.k.a. OS/400) has been built on memory-mapped I/O from the beginning (circa 1988.) (And it has a DB-driven "filesystem" that Microsoft has been unable to ship despite about 25 years of failure.)
I know it's not quite the same thing, but I cannot imagine that this new O/S will somehow eliminate the need for flash and/or disk. I don't see them managing to get the memristor cost down enough to entirely replace disk/flash. If they had actually shipped some of the things before now, I could maybe believe it, but they haven't.
Well, Meg Whitman had the guts to say "Find them some money" when HPLabs proposed the "Machine." I wish HP all the success.
It is about time some corporation stepped up to the plate other than Apple and jump-starts mega-improvement in major devices.
My first time sharing "Mini-computer" (was not mini sized), desktop engineering computer (using mag-strips pre-HP45), & then the HP35-41-45-75 were all incredible computing devices for their day.
What's the point of running *nix on it? If the architecture is so much different that they have to rewrite tons of OS code to support it, why not just build their own?
*nix is the fastest path to a stable and highly usable platform. Only a small portion of *nix interfaces with the architecture. They only have to rewrite that small portion.
Plus with *nix you have a rather large base of application software to run as well.
That said, could other parts of *nix or apps be reworked to take advantage of the architecture, possibly. But such efforts do not need to be part of v1.0.0. They can be part of subsequent versions if and when profiling indicates an issue or opportunity.
The article tells me it's bullshit. Applications aren't written to wait for the memory bus; they're written to ask the kernel for resources, and handle that by waiting or operating asynchronously. If they wait, then they just block until the kernel returns--they don't go, "Oh, it's going to be a while, so I'll execute getSomeTea()..." There's nothing in applications to deal with timing.
From an OS perspective, execute-in-place has been a thing for years. Linux run from NAND uses XIP, hence why some JFFS2 configurations compress and some don't. Many implementations don't compress in small-RAM embedded systems, using MMIO to map the JFFS2 file system as a physical memory address and jump to it accordingly. That means Linux loads an mmap()ed binary into VMA by creating a page table entry that points to the MMIO page associated physically with the NAND, and not with any real RAM.
Support my political activism on Patreon.
The new computer does not run on electricity. It runs on a new fuel cell that requires ink.
While HP Labs may not be what it was, it is good to see that HP finally has a CEO that will give them the funding they need to go for the big ideas. We need more research and development funding period. The government needs to increase funding for the NSF and other organizations. And, yes, big companies need to start making long term investments. Microsoft Research is growing. It seems HP Labs is growing again.
Let's hope other big players step up too. I'm tired of money being thrown at yet another mobile application and having that being held up as a paragon of innovation. People are being critical of HP investing in this while Facebook throws 19B of assets at a messaging application? What's wrong with this picture?
I doubt it, forever is a long time. But I imagine most OSes for centuries to come will have bsd or linux in their ancestry. It's simply a matter of efficient allocation of resources - a modern OS is a massive, complicated system - why reinvent the wheel when you can adopt extremely flexible existing technology for free? Certainly there may be room for other OSes, but only if you're doing something fundamentally new, and probably initially simple. Otherwise why waste the resources building something from scratch when you could instead spend those resources refining or replacing the specific bits of a 'nix that *almost* does what you want?
And actually I find the prospect heartening. In the consumer market early on we had a wide variety of Oses, one for each machine almost, and all of them were embarrassingly simple by modern standards, and highly incompatible with each other. Then the PC and DOS took over, and it was... well not *good*, but adequate. And the proliferation of DOS, and later Windows opened the consumer world to the easy exchange of software and data, rather than being unable to share your C64 stuff with the CP/M user down the street. Obviously all the non-PC users missed out, but they had become a small minority. The only problem was that Microsoft was an expansive monopolistic tyrant, and any time it expanded into new markets it did everything in it's power to crush any competition, destroying many good products and companies, and leaving us with barely adequate MS products across a wide spectrum of the lucrative business software spectrum. And of course they ruthlessly defended their core OS market, which was so often the key to crushing their competitors.
Then Linux grew up, and today we are beginning to have a vibrantly competitive OS market once again. True, it's mostly Linux-based, but Linux has become so flexible that various distros, especially specialty stuff, can bear little resemblance to each other - and yet software built for one distro can generally be recompiled for another with only minimal porting effort. A world of many varied and competing, yet mostly interoperating OSes is within sight.
Now if we could just settle on some sort of cross-linux application wrapper so that something like PortableApps.com could be possible for Linux I'd be happy. There've been several projects attempting such a thing, but so far none has gained significant traction - the best option so far seems to be to use Windows programs and Wine - I can't tell you how many programs I use that I simply can't find for a modern Linux distro - they get abandoned for one reason or another, and without binary-level backwards compatibility or someone competent and interested in porting them to each new release they become practically impossible to run. Meanwhile I can still run those old DOS 2 programs pretty much anywhere with at most an emulation layer.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
HP made their massive profits by controlling their IP and making everything in-house. In this case, they have outsourced a great deal of this work. As such, it will be in China within 2 years. At that point, whitman will lose everything.
As somebody that used to work for HP, I am saddened by this. They have great tech, but whitman's run for short-term profits is destroying the company.
I prefer the "u" in honour as it seems to be missing these days.
Well, we need some evolution, one way or another. The "page file" is a relic of an ancient time, and needs to vanish from the kernel, along with the difficulty of dealing with potential page faults anywhere in your kernel code.
I suspect they're unifying memory and local storage in a more fundamental way. It would sure make life easier if you could (in user space) just mark some memory as "persistent" when you allocate it, and let the OS worry about caching and performance, but doing that right isn't easy or obvious.
As "disk" performance gets closer to RAM, new approaches become practical. Previous attempts to unify memory and disk went nowhere as disk was just too slow to take explicit file control away from devs. Previous attempts to do away with directory-based filesystems and go with a sea of tagged documents and a metadata database have crashed on the rocks of low disk performance. But those ideas are good in principle, they just weren't appropriate for actual hardware.
Fast persistent memory changes what it's practical to do, and fanciful new approaches to the basics of OS design are suddenly no longer academic wankery.
Socialism: a lie told by totalitarians and believed by fools.
Taco Bell does not make any sense, anywhere.
FTFY
This issue is a bit more complicated than you think.
I'm sitting in the conference room where this was just announced at the HP Discover conference. The idea is to use photonics for interconnects, so that the limitations of copper don't require physical proximity to memory. And they want to use oxygen atoms with doubly-negative charge (ions) for data storage. The concept is to partner with universities to do some fundamental research and major changes in OS design to have a machine that can scale processor access to 160 PB of memory storage in microseconds.
None of this comprises fundamentally new ideas, but they are working hard to actually make it happen, which is pretty cool.
Eh? Ever used as AS/400 (System i)? Only the biggest-selling mini-computer system of its time. OS/400 had "flat" addressing, treats disc addresses and memory as the same space. And don't give me that BS about performance - I used to run an entry-level model (9406 E35) supporting >250 green screens with 48 MB (yes, megabytes) of main memory, and still achieve sub-second response times at the terminals. Response times at the Windows PCs were a bit slower, but they were using screen-scraped adaptations of the terminal-based programs.
UNIX/linux-based systems are certainly flexible and relatively cheap, but they're not the only solution. If HP goes about this the right way, there could be a specialist market for it.
I was sysadmin on an AS/400 back in the 90's. I am pretty sure we had an E35 somewhere in the cycle of upgrades. I know we started off with something "lower", but still a 35. I think it was a B35. I would not say it was fast, but it was fast enough.
We had remote offices, SDLC lines CSU/DSUs and workstation controllers. I don't think we had 250 terminals, but we did have more than 100.
The last upgrade we did was to a PowerPC based CPU. Ran a tape, swapped a card, instantly faster. Field rep allowed me to do the card swap.
It was a good machine. The HAL was for everything, not just the OS. When we did the upgrade I spoke of, we didn't have to recompile user apps, the tape loaded the new HAL, I expect.
emt 377 emt 4
I have a feeling when a large number of projects on github (or the new dockerhub) includes a Dockerfile and maybe a file for orchestration (like OpenStack Heat template) that will make it even easier to deploy any project things will really start to take off even more than they are now for open source and free software.
New things are always on the horizon
Previous attempts to do away with directory-based filesystems and go with a sea of tagged documents and a metadata database have crashed on the rocks of low disk performance. But those ideas are good in principle, they just weren't appropriate for actual hardware.
They were always a terrible idea because they don't scale in the human mind. For a music collection you can just about deal with artist name, album name, song name... But even when it comes to things like "genera" how many people can remember if a particular song they want to hear counts a pop, or rock, or soft rock, or maybe it was prog-rock, or is that "prog rock" or "progrock"?
It gets worse for documents. With a folder system you can drill down. It serves as a memory aid. With tags you need to search and sift through search results unless you can remember the name of that particular thing you needed, or some other fairly unique identifier. I'd contend that tagging is more effort than organizing in folders too, especially if you want to change tags in bulk without separating collections of related documents accidentally.
There are ways to reduce these problems with fuzzy search terms, hierarchical tags and the like, but they are all just lame attempts to polish a turd.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC