Slashdot Mirror
David Patterson Says It's Time for New Computer Architectures and Software Languages (ieee.org)
Tekla S. Perry, writing for IEEE Spectrum: David Patterson -- University of California professor, Google engineer, and RISC pioneer -- says there's no better time than now to be a computer architect. That's because Moore's Law really is over, he says : "We are now a factor of 15 behind where we should be if Moore's Law were still operative. We are in the post -- Moore's Law era." This means, Patterson told engineers attending the 2018 @Scale Conference held in San Jose last week, that "we're at the end of the performance scaling that we are used to. When performance doubled every 18 months, people would throw out their desktop computers that were working fine because a friend's new computer was so much faster." But last year, he said, "single program performance only grew 3 percent, so it's doubling every 20 years. If you are just sitting there waiting for chips to get faster, you are going to have to wait a long time."
A SPECint graph shared on Quora shows this slowdown starting back in 2005.
https://qph.fs.quoracdn.net/ma...
3. Profit!
2. ???
1. On Soviet Slashdot, a Beowulf cluster of alien Natalie Portman overlords welcomes YOU!
I worked on the BiiN project. https://en.wikipedia.org/wiki/... A 'capability' was a specific -hardware protected- feature that was set up to be unforgeable and contain access rights. This computer architecture approach date back to the Burroughs 6500 https://en.wikipedia.org/wiki/... and even back to some aspects of MULTICS.
They're definitely not von Neumann architectures, since a capability pointing to executable code is a very different thing than a capability pointing to data. In many respects, these would be "direct execution engines" for object-oriented languages (even C++, with some restrictions on that language's definition).
A huge part of this is getting over the illusion that you have any clue about the (set of) instructions generated by your compiler. If you're working on a PDP-8 or even PDP-11, C might well be close to 'assembly language'. But with the much more complex instruction sets and compiler optimizations to support those instruction sets, most languages are far removed from any knowledge of what the underlying hardware executes.
Um, all modern processors are RISC. Careful who you are calling an idiot.
This all points back to software devs. I've spent 2 decades dealing with low-level drivers and optimizations in assembly language. Now, not that I would expect developers to write assembly language, the problem I run into is that software developers of high level languages can't even write efficient code at their level. On top of that, they don't even understand how the language stack works, what code constructs give better performance in one language versus another. In addition, they can't even profile their code anymore or look at logs.
If anything needs changing, it's software developers first. They keep eating up all the computer resources and say "get more this/that for your computer." No, pull your head out of your 4th point of contact and learn to write efficient code. We were doing this shit in the 90s all the time. We even advertised for assembly programmers in NEXT Generation magazine, constantly!
While there's nothing wrong with using high-level languages, programmers today have lost the art of what it means to be lean and mean. I don't hire any developer unless they can demonstrate they know the stack for the language in which they use.
Me: "Oh, no assembly language experience?"
Applicant: "Oh, no. Is that required here?"
Me: "In rare cases, but I'm trying to understand if you even understand how a computer works at a fundamental level. In fact, have you ever worked with state diagrams?"
Applicant: "No."
Me: "Okay, you write an application that simply opens a file. What are the failure modes of your application and the opening of the file? Can you draw a state diagram for this?"
Application: "A flow chart?"
Me: "No, a state diagram. Given a set of inputs, I want you to diagram all outputs and failure modes for each state."
Applicants could answer these questions in the 90s and early 00s, but rarely anymore. I blame software devs for this problem. Hardware engineers are always having to pick up the slack and drag everyone up hill because software devs can't pull their own weight.
The oxymoron here is that David uses hardware performance to substantiate his cliam.
The computer revolution went askew taking the hardware track leaving software to rot in 1960â(TM)s state of the art computer science.
The next revolution is soft not hard.
My whole life the main factor leading to people accepting sucky software is that the hardware is always getting better, and by the time they ship it it runs "fast enough" on the new hardware.
I've been anticipating this for decades; eventually computing power is "good enough" that people start actually trying to write good software. In my view the hardware is at that point, and time is ripe for software changes. And this will lead to tool improvements, to be sure. Architectures are likely to change, because a big part of what goes into existing systems is exactly this desire for the architecture to be relevant for a predetermined amount of time! If the hardware isn't improving and you can't just sell people the new version every few years, that radically changes the design considerations for the whole system. So far, that hasn't happened at the consumer level, and I don't know which changes will be successful, but there are likely to be radical changes in system architecture as companies start to design systems for much longer life.
I will make one specific prognostication: As new hardware architectures are introduced, more of the software will be pushed back onto ROMs, and OS kernels will act more like microcontroller libraries where you use system functions that on more expensive hardware is implemented in ROM, and on cheaper hardware the same code gets copied to RAM (as is the case for most of the system now)
Right now, and historically, audio/video subsystems sometimes have "hardware acceleration," certain things like floating point hardware are not always available, some optical scanners have to have their firmware copied from the host driver, some laptops require custom drivers because of custom hardware support/acceleration of various subsystems, and there is no general mechanism to manage any of this. Each subsystem might have a locally-standardized interface, but there is nothing general for those classes of situations. Or at least, to the extent that there is, it is only within the C compilers that it exists. I predict much greater convergence in how these different subsystems are defined and how they interact. Return of the Thick Client! Except the cheap version will be a compatible thin client. And each subsystem will be able to be implemented as hardware, local software, or cloud services.