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.
Hey, I know. We should use asychhronous techniques! At both the circuit and the architecture level. (P.S. This is sarcasm, which students of Digital Logic and Computer Engineering may find amusing.)
The other half of the joke is that async I/O was the big new feature of a recent C# version, which means it will be the hot new thing in Java in another couple of years.
Java NIO (Non-blocking I/O) was introduced in Java 4 (2002).
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.
We have hit that wall. This technology is mature and everything it can do well, it can do now at close to maximum-possible speeds. Sure, software sucks today and coders are mostly incompetent and there is some speed increase to be expected from that angle, but that is it. That there was an area of seemingly exponential growth does in no way imply it will continue without limits. And it does not.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Depends on what your definition of "need" is. For example, I could say I need to run Minecraft with 220 mods, at 30 FPS, with hundreds of machine blocks. (with an i7-7700k I usually get around 11-12)
The straight up implementation of the Multi MMC Predictor algorithm over 1,000,000 symbols takes 20 minutes to run on my laptop. That's a problem when you want to test every device in a production line. I'll happily take a faster CPU.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
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.
CLR
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
Actually I would disagree with you the number of applications waiting for more computing power has diminished over time. When is the last time gaming was held up by processing? Going to 4k gaming is an exercise in diminishing returns.
love is just extroverted narcissism
The 500 Plus in 1995 was nothing to brag about.... it was still using a 68000 processor when other Motorola machines like Macs were on 68060s (at ten times the clock rate). Now if you had said "1985" then it would be impressive (the Amiga's initial release date).
I ran a modern web browser on a PowerMac G3 (1999).... slow as snails. Ditto on a Pentium 4 at 3000 megahertz. SD video is okay, but HD video runs like molasses.
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
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
More cores are worthless for many implementations of most tasks, which is not the same as being worthless for the task itself.
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?
When is the last time gaming was held up by processing?
Factorio? Kerbal Space Program? Dwarf Fortress? Any game that does heavy simulation?
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
Trouble was, RISC solved a problem that was temporary - lack of space on the silicon.
There is the core of your misunderstanding. The idea of RISC was not to use fewer transistors, but to have a simpler, more orthogonal instruction set with homogenous stages all running in about the same time to enable high clock speeds and pipelining. And yes, there are excellent RISC designs out there - ARM is one, and so is RISC-V. "CISC" nowadays is 99% RISC - they copied the large register sets with x86_64, and they have broken down the CISC instructions into microops that are executed RISC style since roughly forever.
Stephan
If only I could get every slashdotter to take an hour out from flaming and look over the mill architecture diagram: http://millcomputing.com/wiki/... Or burn an hour grokking some part of it they might want to understand (ivan is a trip to watch) https://millcomputing.com/docs... It would be a better world. The Mill folk think way out of the box.
But this is the thing. I work on an asynchronous back end application written in javascript (stupid design decision, I wasn't around at the time). It uses all of one core and nothing from other cores so there is little I can do to give it more resources to work on. If the JS virtual machine could cope with working across multiple cores, then all would be good.
Thats what this article is about, and its a good question.
http://michaelsmith.id.au