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."
We've only had three new ones come out this week. We need M0AR! M0AR languages!! M0AR syntaxes!!
M0AR of all the things!
In fact, it should be a requirement for all CS majors to develop their own language before graduations, so everyone can be *THE* subject matter expert in a language. That would be awesome. Everyone would be able to charge $500/hr for being the ONLY expert in their language.
What could be wrong with this??
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 am pretty sure David Patterson is out there doing it. He is a professor in the field who has accomplished plenty. He is 70 now and is likely past his academic prime, so now he is doing what he should be doing at this time in his career: teaching, mentoring, and inspiring the next generation.
-- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
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.
Moore's law predicted early exponential growth in semi-conductors, but as in all fields it eventually hits an inflection point and becomes asymptotic, infinite transistor density will never happen.
Because Moore's law is more about transistor density. It's an easy nit to pick.
It's still a big deal that we aren't getting any easy gains on single core speed, or, factoring in all their new fancy branch predictions, single thread performance. But newer CPUs are fitting more cores in, newer GPUs are wildly more effective (at a fundamentally parallel task). These are the arguments for Moore's law actually being still online.
Anyone who was around for the late 90s or before knows that computers simply aren't doing what they did before- completely obliterating previous generations of computing. A machine from 2008 can run most current games, and those it can't inherit their restrictions artificially (a motherboard that won't take a new enough GPU, for instance). It can certainly run the latest version of pretty much any OS, and many productivity programs. If you do that comparison from 1999 to 1989, it's a joke- a Pentium III at nearly a gigahertz compared to a 486 at like 50 or 66 megahertz. Look back again at 1979, and you are comparing to an 8086 or something.
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.
Maybe can eliminate shared libraries, dynamic linking and other archaic constructs that came into existence to protect scarce resources like RAM and disk space. Let's put each process in its own 'jail' like existence with closely monitored mechanisms for communication between processes.
Suppose you were an idiot. And suppose you were a member of congress. But then I repeat myself. -- Mark Twain
As I posted above Moore's Law says "transistors will double every 2 years". That held true until 2015, when it slowed to 2.5 years (not a huge difference).
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
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.
so.. slightly delayed then?
Show me an architecture that would make me want it. With C++ as a platform language
"Show me a new vehicle to replace the carriage. It has to include a horse."
Ezekiel 23:20