ARM Pioneer Sophie Wilson Also Thinks Moore’s Law is Coming to an End(nextplatform.com)
nextplatform.com
ARM Pioneer Sophie Wilson Also Thinks Moore’s Law is Coming to an End
https://www.nextplatform.com/2017/04/13/arm-pioneer-sophie-wilson-also-thinks-moores-law-coming-end/
111 comments
My pretentious 2 cents: check out Moore Forth CPU, his greenarrays are either memory or processors depending on your view. It makes the issue disappear in a way. It's also madenningly beautiful to program since each memcessor can send/receive closures from neighbors. There's a talk from Moore on this on youtube.
ps: also mostly clockless and microwatt range
ps: also mostly clockless and microwatt range
I've always admired the Sh-Boom. Ahead of its time and hence the subject of a lot of patent litigation when time caught up.
https://www.dnd.utwente.nl/~tim/colorforth/PTSC/IGNITE_Proce...
Faster than clock processing before that was a thing.
https://patents.google.com/patent/US5440749A/en
https://www.dnd.utwente.nl/~tim/colorforth/PTSC/IGNITE_Proce...
Faster than clock processing before that was a thing.
https://patents.google.com/patent/US5440749A/en
where were you all my life
What are some practical things done with GA's chips? (My own belief is that almost nothing can be done with them but I'm always glad to be surprised, certainly with something like this where the chip itself is a masterpiece of circuit design shunning every convention of the art.)
Beside inspiring the shit out of me I have no idea. You have to trust a tad my internal feeling for beauty. If I could I'd ask Moore directly, he surely had very practical applications since he created Forth chips (I remember CAD and VLSI projects).
That's the thing with these guys, you're never sure if they're insane or just that the world doesn't tune enough to their ideas.
That's the thing with these guys, you're never sure if they're insane or just that the world doesn't tune enough to their ideas.
It seems like an systolic array architecture using Forth processors as the processing nodes. Good for some things like neural networks like Google is doing with their own chips. There is also Parallela which was on Kickstarter. But I'm not sure if Moore is doing anything fundamentally new unless their compiler can automatically convert a conventional program into systolic array form?
Moore is also quite old (80), I'm even worried about his passing from time to time. So I suppose he's not doing much ambitious things but enjoying himself.
Parallela has managed to conduct a very succesful KickStarter. They've been under the radar since but still active, they published new plans for 1000 core coprocessor array. And I suppose, now they've proved themselves alone, they won't stop soon.
Parallela has managed to conduct a very succesful KickStarter. They've been under the radar since but still active, they published new plans for 1000 core coprocessor array. And I suppose, now they've proved themselves alone, they won't stop soon.
You might want to check out "A Systolic Array Optimizing Compiler" -> https://books.google.com/books?id=6nTjBwAAQBAJ&lpg=PA188&ots...
Systolic array/vector processors have been used since the late 60's for neural and other gemm heavy workloads. The Warp architecture from CMU is an excellent example.
Systolic array/vector processors have been used since the late 60's for neural and other gemm heavy workloads. The Warp architecture from CMU is an excellent example.
Well I mean aren't they basically just an 18-bit transputer? I don't know if there's anything they'd excel at that you couldn't get from a more familiar architecture but people figured out how to do things on transputers.
Imagine a complex prolog search (great for stuff like natural language processing and program optimization), with the non-deterministic clauses spread through those nodes, and collecting the true ones on the later stage processors.
Maybe we should attack the memory wall problem first, since it promises a big acceleration in some areas, and it's not strictly related to limits of physics, like lithography ?
One way to do so is silicon photonics: it's possible to achieve 280 tbps bandwidth for 168W @ chip area of 4mm2 for 168W. Or you could triple that but you'll need ~1.5KW .
This of course will require better cooling, but DARPA has a project, using microfluidics channels, that can cool 1KW/cm2 and 30KW/cm2.
And as for power delivery - with TSV's you can deliver 150W/cm2.
And sure, such chips may be more expensive both in cost and power than today's are. But infinite memory bandwidth and photonics can make programmer's lives so much easier, and offer great acceleration in memory constrained problems, and make new architectures feasible(network computers with infinite bandwidth?). So maybe there's an initial market ?
And once we're there, and money starts flowing, maybe we'll see another type of "moore's law" focused on reducing the costs of cooling/photonics/power-delivery?
And BTW, some good news: ST(i think) is opening a photonics fab.
links:
https://www.extremetech.com/extreme/224516-microfluidics-dar...
https://pdfs.semanticscholar.org/4f9b/d24ea869f64c4457f69ad6...
http://drum.lib.umd.edu/bitstream/handle/1903/17153/TR%20DRU...
One way to do so is silicon photonics: it's possible to achieve 280 tbps bandwidth for 168W @ chip area of 4mm2 for 168W. Or you could triple that but you'll need ~1.5KW .
This of course will require better cooling, but DARPA has a project, using microfluidics channels, that can cool 1KW/cm2 and 30KW/cm2.
And as for power delivery - with TSV's you can deliver 150W/cm2.
And sure, such chips may be more expensive both in cost and power than today's are. But infinite memory bandwidth and photonics can make programmer's lives so much easier, and offer great acceleration in memory constrained problems, and make new architectures feasible(network computers with infinite bandwidth?). So maybe there's an initial market ?
And once we're there, and money starts flowing, maybe we'll see another type of "moore's law" focused on reducing the costs of cooling/photonics/power-delivery?
And BTW, some good news: ST(i think) is opening a photonics fab.
links:
https://www.extremetech.com/extreme/224516-microfluidics-dar...
https://pdfs.semanticscholar.org/4f9b/d24ea869f64c4457f69ad6...
http://drum.lib.umd.edu/bitstream/handle/1903/17153/TR%20DRU...
The memory wall is not a bandwidth issue, but a problem of (concurrent - many more strands of execution than memory channels) latency and there are as far as I know pretty much no ideas how to fundamentally address that (DRAM alternatives might, but so far were all rather disappointing even compared to much older DRAM).
You can add more channels and more ranks into the system, which gives some small linear increase w.r.t. to concurrency, but brings a a big (channels) or minor (ranks) power increase. This doesn't change non-concurrent latency, so does not help sequential workloads.
You can add more channels and more ranks into the system, which gives some small linear increase w.r.t. to concurrency, but brings a a big (channels) or minor (ranks) power increase. This doesn't change non-concurrent latency, so does not help sequential workloads.
Latency is more important than just bandwidth, and since RAM is pretty far away from the ALU you'll quickly hit limits there.
What if instead of passing a fetch across the bus, you passed a tiny little program that included conditional indirections - if you want to get x.y.z, you'd have a list of two indirections and an offset in the little program.
Push the latency problem of pointerful code closer to the data.
Push the latency problem of pointerful code closer to the data.
Here's an even simpler one: double lookup. Fetch a block of memory at the address stored in this memory address (which I may not have fetched already).
Our data hierarchies create graphs that have lots of internal pointers in them, and we are constantly warned about the cost of pointer indirections. Memory already knows how to deal with addresses. Teaching it to chase pointers should be easier than teaching it Boolean math.
[edit: it appears the real limitation to both our ideas is that virtual memory prevents you from making any decisions on the wrong side of the MMU. You could only ever make conditional fetches from the same page, which could be slightly useful but would be so hard to use I don't know who would bother]
Our data hierarchies create graphs that have lots of internal pointers in them, and we are constantly warned about the cost of pointer indirections. Memory already knows how to deal with addresses. Teaching it to chase pointers should be easier than teaching it Boolean math.
[edit: it appears the real limitation to both our ideas is that virtual memory prevents you from making any decisions on the wrong side of the MMU. You could only ever make conditional fetches from the same page, which could be slightly useful but would be so hard to use I don't know who would bother]
This does not work, because the latency of accessing memory is inherent to it. It's simply the time required to open a DRAM row (or charge bit lines), which stays more or less the same independent of process scaling. Moving the pointer chasing closer to the memory does not change this larger delay.
That would be nifty. Though a radical departure from the status quo. Not to say it couldn't be done.
Currently DRAM is designed to fetch large pages at a time which are cached in the CPU. Cache is highly beneficial to latency when there is good memory locality in the program being run.
Currently DRAM is designed to fetch large pages at a time which are cached in the CPU. Cache is highly beneficial to latency when there is good memory locality in the program being run.
The distance isn't a big issue. It's trivial to put the RAM close enough that the signals spend less than a nanosecond in transit on a round trip.
It's all about the speed of the memory itself.
It's all about the speed of the memory itself.
1ns is already two cycles at 2GHz and that doesn't count the switching delays of all the transistors between the memory cell and the register.
If RAM lookups only cost 2 cycles they would beat L2 and L3 cache.
The real problem is the speed of the RAM, not the distance, for now. When RAM gets a request it can take many cycles to respond, sometimes as many as 50 or 60 before the first byte is returned.
If you are smart you can request large sequential chunks and after the first bytes things come down to the the CPU very fast, but that initial hit is still something a lot of people optimizing algorithms are wrestling with.
The real problem is the speed of the RAM, not the distance, for now. When RAM gets a request it can take many cycles to respond, sometimes as many as 50 or 60 before the first byte is returned.
If you are smart you can request large sequential chunks and after the first bytes things come down to the the CPU very fast, but that initial hit is still something a lot of people optimizing algorithms are wrestling with.
Latency is more important than bandwidth but it's also a lot harder. You're running into c and c is a constant.
Actually, the latency of DRAM isn't necessarily caused by physical transport, but the speed of the memory itself.
You could get 10x better perf and easier programmability , for starters.
What? In my experience SiP tends to be more energy efficient than CMOS interconnect transport.
>Having to use extreme ultraviolet (really soft X-rays) for lithography runs costs way up. EUV "light sources" are insanely complex, involving heating falling droplets of metal to plasma levels with lasers. It's amazing that works as a production technology.
The first time a hardware-side friend explained this to me, I was 100% certain he was BSing with hyperbole to emphasize the difficulties involved.
Now that I know otherwise, I am still amazed that such a complex method is the easiest one we have. It certainly makes some of my complaints regarding the complexity of software feel trivial!
The first time a hardware-side friend explained this to me, I was 100% certain he was BSing with hyperbole to emphasize the difficulties involved.
Now that I know otherwise, I am still amazed that such a complex method is the easiest one we have. It certainly makes some of my complaints regarding the complexity of software feel trivial!
I think the best way to quickly get a sense of the difficulty is "Somehow it's harder than using photons that wiggle back and forth by 193nm to carve out 14nm shapes."
> GPUs have turned out to be more generally useful than expected.
It's not only raw power. GPU programming comes with builtin asynchronism (waiting on promises of computations, so you can hide latency) and a memory hierarchy (local, block, global, host memory) each one being more local and smaller than the next level. This makes caching much more efficient, since a lot of values don't need to escape the thread/warp/block. The problem on CPUs is that memory is flat and considered equal.
It's not only raw power. GPU programming comes with builtin asynchronism (waiting on promises of computations, so you can hide latency) and a memory hierarchy (local, block, global, host memory) each one being more local and smaller than the next level. This makes caching much more efficient, since a lot of values don't need to escape the thread/warp/block. The problem on CPUs is that memory is flat and considered equal.
> The problem on CPUs is that memory is flat and considered equal.
CPUs have a similar memory hierarchy, the difference is that you're a context switch away from losing your preciously cached data. Even in GPUs memory is more often than not a constraint on the speed of computation, it is very easy to starve a GPU by accident.
My personal favorite trick to see if I'm using my GPU effectively is to run a benchmark on it to max it out and register the power consumed with an e-meter. As long as I don't hit that power level in my own application there are still improvements to be had (and I almost never manage to reach the maximum but I'm happy with 60 to 80% or so of that). It's one of the dumbest debugging tricks ever but it is surprisingly effective at figuring out if I've laid out memory access patterns properly.
CPUs have a similar memory hierarchy, the difference is that you're a context switch away from losing your preciously cached data. Even in GPUs memory is more often than not a constraint on the speed of computation, it is very easy to starve a GPU by accident.
My personal favorite trick to see if I'm using my GPU effectively is to run a benchmark on it to max it out and register the power consumed with an e-meter. As long as I don't hit that power level in my own application there are still improvements to be had (and I almost never manage to reach the maximum but I'm happy with 60 to 80% or so of that). It's one of the dumbest debugging tricks ever but it is surprisingly effective at figuring out if I've laid out memory access patterns properly.
What I wanted to say is ith the GPU, memory access have a known latency (you are writing to the L1 equivalent) without a statistical component.
Also the nature of tasks submitted on the GPU (reified) makes it easier to optimize imho.
That's pretty inaccurate as a rule. TDPs are specified for a standard graphics workload. Compute tasks can easily draw between 50% and 150% of the rated TDP. A given task may bottleneck on bandwidth or some other limit long before it hits a high level of TDP (which may fall into the generic 'unsuited for GPU' category and can never really be optimized).
So apart from a generic inspiration to keep going further, this really does nothing for you. In fact you may still have further performance gains possible after this heuristic tells you to stop.
So apart from a generic inspiration to keep going further, this really does nothing for you. In fact you may still have further performance gains possible after this heuristic tells you to stop.
I usually have a pretty good idea how much utilization I should see, it's just a quick way to make sure I get what I'm aiming for and it has definitely helped me on a number of occasions when performance was disappointing to point out the GPU was simply starved. Memory access for a GPU is everything, even one detail wrong and you could easily get a 50% or more performance penalty so it is handy to have a quick confirmation that you're in the ballpark.
It's not suitable as a detailed profiler.
It's not suitable as a detailed profiler.
Advantage of big, fat CPU cores: They have tons of performance counters :)
>> CPUs have a similar memory hierarchy, the difference is that you're a context switch away from losing your preciously cached data.
That's an argument for more cores, each with it's own cache. It also suggests that the OS schedule all of the low CPU load tasks on the same core to prevent context switching on the big workloads. I'm not sure if that's how it's done today, but when my dual core is busy the CPU usage graphs tend to switch places regularly.
That's an argument for more cores, each with it's own cache. It also suggests that the OS schedule all of the low CPU load tasks on the same core to prevent context switching on the big workloads. I'm not sure if that's how it's done today, but when my dual core is busy the CPU usage graphs tend to switch places regularly.
There are more levels of caching, some shared, some not.
For instance, in a one particular quad core CPU all cores would have their own L1 cache, but cores 0 and 1 share the same L1 cache, and cores 2 and 3 another L1 cache. Then finally all cores share the same DRAM. So depending on whether your tasks have been 'pinned' to a certain core you might see a smaller or bigger hit when there is a context switch and a migration of a task that is not pinned to a certain core might flush L1 or both L1 and L2.
Of course every architecture has its own quirks so to gage the impact you'd have to know exactly how things are set up in that particular machine.
Another set-up (the one I'm writing this on) has 32 K per core L1 cache, 256K L2 cache and a 15 MB shared L3 cache.
Migrating from one core to another on this machine is cheaper than on the four core example above.
For instance, in a one particular quad core CPU all cores would have their own L1 cache, but cores 0 and 1 share the same L1 cache, and cores 2 and 3 another L1 cache. Then finally all cores share the same DRAM. So depending on whether your tasks have been 'pinned' to a certain core you might see a smaller or bigger hit when there is a context switch and a migration of a task that is not pinned to a certain core might flush L1 or both L1 and L2.
Of course every architecture has its own quirks so to gage the impact you'd have to know exactly how things are set up in that particular machine.
Another set-up (the one I'm writing this on) has 32 K per core L1 cache, 256K L2 cache and a 15 MB shared L3 cache.
Migrating from one core to another on this machine is cheaper than on the four core example above.
> but it's hard to see what 20 or 100 CPUs would do for a laptop.
This only if we want to keep the laptop in its current definition: a clunky device requiring lots of cables and holes in the casing, showing flat image at 4K at best and average quality audio, typing every single letter of a every command to get something done. No useful voice recognition/speech synthesis, no gesture tracking etc.
Specialized (sub)systems (media, wireless, smart networking) already use dozens of CPUs. Having generic CPUs to do the same work is not currently justified, mostly because of power and memory consumption. As these will go down, generic CPUs will assume more and more specialized tasks, because they are always easier to program, and probably cheaper to use overall (licenses, software and hardware tooling etc)
Thinking about it, 20 CPUs in a laptop seems like a minimum to me.
This only if we want to keep the laptop in its current definition: a clunky device requiring lots of cables and holes in the casing, showing flat image at 4K at best and average quality audio, typing every single letter of a every command to get something done. No useful voice recognition/speech synthesis, no gesture tracking etc.
Specialized (sub)systems (media, wireless, smart networking) already use dozens of CPUs. Having generic CPUs to do the same work is not currently justified, mostly because of power and memory consumption. As these will go down, generic CPUs will assume more and more specialized tasks, because they are always easier to program, and probably cheaper to use overall (licenses, software and hardware tooling etc)
Thinking about it, 20 CPUs in a laptop seems like a minimum to me.
>No useful voice recognition/speech synthesis, no gesture tracking etc.
Those are gimmicks anyway. Unless incapacitated for some reason, nobody wants to talk to their programs -- except if it is combined with very advanced/strong AI to just utter some command and have them figure out all the rest (try talking out aloud for an hour for e.g. writing a post -- it gets old very soon). Making gestures in the air even less so, unless you want to switch on the lights (e.g. something you do very rare) or play a gesture tracking game to get fit. Those Minority Report style UIs is something that goods look in movies, but is not a good idea in practice (just like the translucent glass monitors they use in those movies. What's the idea there, who thought that, outside of a HUD, it makes sense to have anybody/anything on the other side of the glass compete with the on-screen data for your attention?).
>a clunky device requiring lots of cables and holes in the casing, showing flat image at 4K at best and average quality audio, typing every single letter of a every command to get something done. No useful voice recognition/speech synthesis, no gesture tracking etc.
You make the pinnacle of modern technology sound bad. Perhaps born quite recently and lacking some context?
Some of the sneer doesn't even make sense. "4K at best" -- the eye has a certain physiology, and for a laptop screen that's 15 or even 17 inches beyond 4K is marginal returns (and after that, no returns at all).
And "average quality audio"? Not sure what you have in mind, but audio in laptops is constrained by the speakers, not by the soundcard or CPU. It's trivial to have a great DAC in a laptop that can do 192Khz/24bit that's better than what a human can hear (or even tolerate: 24bit dynamic range allows for building-crushing audio).
Those are gimmicks anyway. Unless incapacitated for some reason, nobody wants to talk to their programs -- except if it is combined with very advanced/strong AI to just utter some command and have them figure out all the rest (try talking out aloud for an hour for e.g. writing a post -- it gets old very soon). Making gestures in the air even less so, unless you want to switch on the lights (e.g. something you do very rare) or play a gesture tracking game to get fit. Those Minority Report style UIs is something that goods look in movies, but is not a good idea in practice (just like the translucent glass monitors they use in those movies. What's the idea there, who thought that, outside of a HUD, it makes sense to have anybody/anything on the other side of the glass compete with the on-screen data for your attention?).
>a clunky device requiring lots of cables and holes in the casing, showing flat image at 4K at best and average quality audio, typing every single letter of a every command to get something done. No useful voice recognition/speech synthesis, no gesture tracking etc.
You make the pinnacle of modern technology sound bad. Perhaps born quite recently and lacking some context?
Some of the sneer doesn't even make sense. "4K at best" -- the eye has a certain physiology, and for a laptop screen that's 15 or even 17 inches beyond 4K is marginal returns (and after that, no returns at all).
And "average quality audio"? Not sure what you have in mind, but audio in laptops is constrained by the speakers, not by the soundcard or CPU. It's trivial to have a great DAC in a laptop that can do 192Khz/24bit that's better than what a human can hear (or even tolerate: 24bit dynamic range allows for building-crushing audio).
Trying to give a short reply, so think about two use cases:
a) laptop as a back-end for complex measurement system. Connected to a high-voltage signal, sitting in a crowded labs full of noise and cables. Would you like to reach out to type in a command every time, if you can speak or gesture instead?
b) laptop put next to a rendering device (video, audio, whatever), close enough so a wide-band wireless becomes efficient. Would you like to have all rendering devices perform the same computation, closed-sourced, paid-licensing, full of non-addressed CVEs? Or you'd rather concentrate the same processing in one place -- your laptop -- source code open to public inspection etc?
a) laptop as a back-end for complex measurement system. Connected to a high-voltage signal, sitting in a crowded labs full of noise and cables. Would you like to reach out to type in a command every time, if you can speak or gesture instead?
b) laptop put next to a rendering device (video, audio, whatever), close enough so a wide-band wireless becomes efficient. Would you like to have all rendering devices perform the same computation, closed-sourced, paid-licensing, full of non-addressed CVEs? Or you'd rather concentrate the same processing in one place -- your laptop -- source code open to public inspection etc?
>a) laptop as a back-end for complex measurement system. Connected to a high-voltage signal, sitting in a crowded labs full of noise and cables. Would you like to reach out to type in a command every time, if you can speak or gesture instead?
First, wouldn't that be a totally niche use? I'm pretty sure people who can't type (e.g. no hand control due to some accident/condition) are far more than people in "crowded labs full of noise and cables" using their laptop as a "back-end for complex measurement system".
So, I didn't say there are no uses for speech/gesture control (I even pointed to incapacitated users and such). I said it's gimmicky for most people, and this is not really a counter-example to that.
But those things aside, if the lab is "crowded" and "full of noise" wouldn't that make speech commands either perform badly (due to the noise in the room), or further annoy the others in the lab (due to them adding to the noise)?
That leaves gestures. But those wont work for complex commands, but just for stuff like "pick among a few options". Else you'd have to learn a whole gesture based language (like sign language). I'd take typing then -- or some special controller that encodes the options (e.g. a foot switch).
>b) laptop put next to a rendering device (video, audio, whatever), close enough so a wide-band wireless becomes efficient. Would you like to have all rendering devices perform the same computation, closed-sourced, paid-licensing, full of non-addressed CVEs? Or you'd rather concentrate the same processing in one place -- your laptop -- source code open to public inspection etc?
I'd call this out as another totally niche and contrived example. And my laptop is not "source code open to public inspection" anyway, much less the hardware in it. So why would I trust the processors in my laptop more than the processors in my rendering device? I bought both anyway, and have not inspected any of them.
First, wouldn't that be a totally niche use? I'm pretty sure people who can't type (e.g. no hand control due to some accident/condition) are far more than people in "crowded labs full of noise and cables" using their laptop as a "back-end for complex measurement system".
So, I didn't say there are no uses for speech/gesture control (I even pointed to incapacitated users and such). I said it's gimmicky for most people, and this is not really a counter-example to that.
But those things aside, if the lab is "crowded" and "full of noise" wouldn't that make speech commands either perform badly (due to the noise in the room), or further annoy the others in the lab (due to them adding to the noise)?
That leaves gestures. But those wont work for complex commands, but just for stuff like "pick among a few options". Else you'd have to learn a whole gesture based language (like sign language). I'd take typing then -- or some special controller that encodes the options (e.g. a foot switch).
>b) laptop put next to a rendering device (video, audio, whatever), close enough so a wide-band wireless becomes efficient. Would you like to have all rendering devices perform the same computation, closed-sourced, paid-licensing, full of non-addressed CVEs? Or you'd rather concentrate the same processing in one place -- your laptop -- source code open to public inspection etc?
I'd call this out as another totally niche and contrived example. And my laptop is not "source code open to public inspection" anyway, much less the hardware in it. So why would I trust the processors in my laptop more than the processors in my rendering device? I bought both anyway, and have not inspected any of them.
> This only if we want to keep the laptop in its current definition: a clunky device requiring lots of cables and holes in the casing, showing flat image at 4K at best and average quality audio, typing every single letter of a every command to get something done. No useful voice recognition/speech synthesis, no gesture tracking etc.
Laptops can be roughly the size of a screen and a battery, and very sleek. They can do all power and I/O through a single USB-C cable. Laptops can do 3D, and if you find a screen that's better than 4K they can do that too. The only real limit is that it's fundamentally one screen, which is pretty minor. Laptops can have great audio. They can do voice recognition and speech synthesis. They can do gesture tracking.
And doing all those at the same time only requires a couple processors.
Laptops can be roughly the size of a screen and a battery, and very sleek. They can do all power and I/O through a single USB-C cable. Laptops can do 3D, and if you find a screen that's better than 4K they can do that too. The only real limit is that it's fundamentally one screen, which is pretty minor. Laptops can have great audio. They can do voice recognition and speech synthesis. They can do gesture tracking.
And doing all those at the same time only requires a couple processors.
> And doing all those at the same time only requires a couple processors.
A couple of general-purpose CPU cores you mean?
How about: at least one CPU in WiFi subsystem, another in the Gigabit Ethernet card, another as high-speed interface host controller, video subsystem probably several (8K resolution / stereo, decoding + transcoding + (de)watermarking + error concealment + post processing), audio one or more (Dolby Volume, spatial sound), demodulation + demuxing of container formats at high speed at least one more maybe?
My point is really -- laptop should be able to do all that great stuff you enumerated, and more yet, all at the same time. As data volumes and our expectations grow, and Moore law comes to end, more cores will be needed, and I say there will be work for more of them than just 4 or 8.
A couple of general-purpose CPU cores you mean?
How about: at least one CPU in WiFi subsystem, another in the Gigabit Ethernet card, another as high-speed interface host controller, video subsystem probably several (8K resolution / stereo, decoding + transcoding + (de)watermarking + error concealment + post processing), audio one or more (Dolby Volume, spatial sound), demodulation + demuxing of container formats at high speed at least one more maybe?
My point is really -- laptop should be able to do all that great stuff you enumerated, and more yet, all at the same time. As data volumes and our expectations grow, and Moore law comes to end, more cores will be needed, and I say there will be work for more of them than just 4 or 8.
Wifi might have a core to handle various things, but you could probably already do that on the main CPU. Ethernet adapters don't need processing, they need specialized transceiver circuits attached to ram. Deciding what to display is already done on a GPU that's almost entirely generic processor. Feeding that to the hardware takes special circuitry and doesn't need any real processing. Audio processing is almost always done on the main CPU already.
I expect more cores to be used in the future, but all the things you mentioned are either already handled on the main cores, or take utterly trivial amounts of processing. They can all be handled on couple cores. They won't be what pushes growth.
I expect more cores to be used in the future, but all the things you mentioned are either already handled on the main cores, or take utterly trivial amounts of processing. They can all be handled on couple cores. They won't be what pushes growth.
> Audio processing is almost always done on the main CPU already.
For a counter-example, look at: http://www.trinnov.com/products/home-theater/magnitude32/spe...
Home Cinema Audio Processor. Intel i5 Quad Core (audio alone). High End. Today.
For a counter-example, look at: http://www.trinnov.com/products/home-theater/magnitude32/spe...
Home Cinema Audio Processor. Intel i5 Quad Core (audio alone). High End. Today.
[deleted]
Typing is faster and more accurate than voice recognition. The advantage of voice is hands-free operation.
The laptop has been somewhat eroded by tablets and hybrids like the Microsoft Surface, but until we get rollup screens the form factor of 10"-17" portable screen with keyboard will continue to exist.
The laptop has been somewhat eroded by tablets and hybrids like the Microsoft Surface, but until we get rollup screens the form factor of 10"-17" portable screen with keyboard will continue to exist.
>> The advantage of voice is hands-free operation.
No, the advantage of voice is natural language queries. Imagine the following:
"<computer name> open the file I was working on yesterday."
"<CN>Find the email from Bob with the attached document on system requirements."
"<CN>Open the calendar and see when I can schedule a meeting with Alice and Jane."
"<CN>Find the picture of <wife> in front of a waterfall from our trip up north."
This requires smart apps that accumulate meta-data about your files and activities. That data then enables natural language communication with the machine, and that is what's needed to make voice recognition worth while. But with all the pieces I think you'll find it very rewarding.
I've often imagined a photo-realistic office assistant in a small window off in the corner that speaks and understands and takes care of things like this. It may seem like a gimmick but that's because nobody has done it correctly yet.
No, the advantage of voice is natural language queries. Imagine the following:
"<computer name> open the file I was working on yesterday."
"<CN>Find the email from Bob with the attached document on system requirements."
"<CN>Open the calendar and see when I can schedule a meeting with Alice and Jane."
"<CN>Find the picture of <wife> in front of a waterfall from our trip up north."
This requires smart apps that accumulate meta-data about your files and activities. That data then enables natural language communication with the machine, and that is what's needed to make voice recognition worth while. But with all the pieces I think you'll find it very rewarding.
I've often imagined a photo-realistic office assistant in a small window off in the corner that speaks and understands and takes care of things like this. It may seem like a gimmick but that's because nobody has done it correctly yet.
I too would welcome general AI, but fear we'll just be stuck with a verbal Microsoft paperclip.
I'd think students listening to a teacher in a auditorium, would appreciate voice recognition, if done with sufficient quality, much more than typing. For me personally it always was either listening/understanding or taking notes.
Possibly, although there are some people who believe that the act of taking notes helps retention. Certainly you'd still have to review the transcript to deal with all the uhming and sidetracking of a live speaker.
Mind you, I'm old enough that I took all my lecture notes longhand. I'd love to see a dictation system cope with maths notation.
(Thinking back, 20 years ago I went to a lecture on the subject of "what on earth will we do with >4Gb of RAM"...)
Mind you, I'm old enough that I took all my lecture notes longhand. I'd love to see a dictation system cope with maths notation.
(Thinking back, 20 years ago I went to a lecture on the subject of "what on earth will we do with >4Gb of RAM"...)
Was one of the options "launch a text chat program called slack and chrome with 3 tabs on websites with movie advertisements"?
In a sense, yes, probably. It is not a new idea that programs will grow to fit all available resources, I'm pretty sure it had been observed by at least the 1970s: http://www.anvari.org/fortune/Laws/2511_laws-of-computer-pro... That reference isn't dated, but I can't seem to find a dated one because it's just the sort of ambient humor that floated around for a long time and got embedded into fortune files and such. Search for that and you find it all over, unattributed.
As I type this, I'm waiting for a process that could have a parallelism of about 9,000 threads but it's running on a mere 12-core machine (compiling a large C++ project). Bring on the "20 or 100 CPUs" for my next computer please. Though, as mentioned elsewhere, this is also likely to hit memory bandwidth limits for affordable systems, not to mention total memory usage limits given that more than a few of those 9,000 compiles peak at >1GB RSS.
As a longtime GPU programmer, agreed 100%! There's still room for more parallel-friendly algorithms and higher memory bandwidth before the party is truly over IMO.
But...
One has to embrace parallel languages instead of single-threaded scripting languages or the music is going to stop playing RSN, no?
But...
One has to embrace parallel languages instead of single-threaded scripting languages or the music is going to stop playing RSN, no?
> but it's hard to see what 20 or 100 CPUs would do for a laptop.
It requires a few assumptions, but here it goes:
1) Assume applications increase their CPU demands significantly over the coming decades. Why? Who knows. Maybe (very plausibly) extremely advanced (compared to today) AI use & integration.
2) Move to, essentially, a CPU per process model
I have a couple dozen processes running on my system. Make the CPUs cheap enough and give me 30 of them.
Perhaps the average system will have four or five major AI agents running locally on it, that are particularly good at various things, and those agents will be constantly running processing intensive tasks (I'm assuming here that ~95% of all AI tasks will be performed in the cloud; which is to say I expect the computing power consumed daily by an individual in ... 30 years to be a hundred plus times what the average user is consuming per day now (doing things like watching YouTube or checking Facebook or running Snapchat or WhatsApp)).
It requires a few assumptions, but here it goes:
1) Assume applications increase their CPU demands significantly over the coming decades. Why? Who knows. Maybe (very plausibly) extremely advanced (compared to today) AI use & integration.
2) Move to, essentially, a CPU per process model
I have a couple dozen processes running on my system. Make the CPUs cheap enough and give me 30 of them.
Perhaps the average system will have four or five major AI agents running locally on it, that are particularly good at various things, and those agents will be constantly running processing intensive tasks (I'm assuming here that ~95% of all AI tasks will be performed in the cloud; which is to say I expect the computing power consumed daily by an individual in ... 30 years to be a hundred plus times what the average user is consuming per day now (doing things like watching YouTube or checking Facebook or running Snapchat or WhatsApp)).
>Assume applications increase their CPU demands significantly over the coming decades. Why? Who knows. Maybe (very plausibly) extremely advanced (compared to today) AI use & integration.*
I'm willing to bet that "extremely advanced AI use" will not come to applications in the "coming decades". It's another fad (in fact a cyclic fad, it had made the same promises back in the 80s), like all the buzzwords that take over an industry for 3-5 years and then give way to the next.
In 2040, for all the predictions for its transformation or demise, the business and home desktop will look more or less like it does now.
I'm willing to bet that "extremely advanced AI use" will not come to applications in the "coming decades". It's another fad (in fact a cyclic fad, it had made the same promises back in the 80s), like all the buzzwords that take over an industry for 3-5 years and then give way to the next.
In 2040, for all the predictions for its transformation or demise, the business and home desktop will look more or less like it does now.
> Why? Who knows.
Possibly for the same reason it's already increasing today: as software becomes more complicated (or complex, depending on your POV), we are shifting toward languages and abstractions better suited to manage that complexity, often at the cost of CPU cycles.
Examples: dynamic dispatch, interpreted code, libraries on top of libraries on top of libraries, boxing of machine-native types, bridging between old unsafe languages and new safe languages, automatic memory management, automatic bounds/overflow checking.
Possibly for the same reason it's already increasing today: as software becomes more complicated (or complex, depending on your POV), we are shifting toward languages and abstractions better suited to manage that complexity, often at the cost of CPU cycles.
Examples: dynamic dispatch, interpreted code, libraries on top of libraries on top of libraries, boxing of machine-native types, bridging between old unsafe languages and new safe languages, automatic memory management, automatic bounds/overflow checking.
I kinda like the idea of this, and that's also one of the reasons I find architectures like the Adapteva Epiphany (the chip that makes the Parallella [1] interesting) interesting. At the moment they're more curiosities because each core is so weak, but they're at least exploring the space of architectures designed for ultra-high core counts (their latest chip is 1024 cores [2], and what makes them different from GPUs is that these are 1024 fully independent cores, running different instruction streams).
The problem, though, remains, that for most systems, unless each core is tremendously weak, you can run most of the ongoing tasks on a typical current desktop system on a tiny timeslice of a single core.
OSs certainly can paralleise more. E.g. AmigaOS relied far more on using multitasking as a basic OS primitive 30 years ago than most modern OSs, because message passing was exceedingly cheap (no memory protection, context switched involved moving a few registers). Something as simple as cut and paste could involve nearly a dozen processes (device drivers for mouse and keyboard, input handler, console device and higher level console handler, a process specifically managing the console clipboard (other apps might handle it themselves), the clipboard handler, the clipboard device, a filesystem handler for wherever the clipboard was mapped, the underlying disk device - usually ramdisk but could be anything, and more depending on setup). That was to make latency predictable first and foremost, at the cost of throughput, but the overall model could be adapted.
But part of the challenge is to write applications this way without just ending up being bottlenecked on the message exchanges.
Even if you can make that cheap enough, we still have the problem of the vast number of tasks that are simply very hard to parallelise. For some of them splitting them up and spreading them out certainly could make things like pipelining processing help us cut latency when something is done repeatedly, but whatever we do, we will have big challenges ahead.
[1] https://www.parallella.org [2] http://www.adapteva.com/announcements/epiphany-v-a-1024-core...
The problem, though, remains, that for most systems, unless each core is tremendously weak, you can run most of the ongoing tasks on a typical current desktop system on a tiny timeslice of a single core.
OSs certainly can paralleise more. E.g. AmigaOS relied far more on using multitasking as a basic OS primitive 30 years ago than most modern OSs, because message passing was exceedingly cheap (no memory protection, context switched involved moving a few registers). Something as simple as cut and paste could involve nearly a dozen processes (device drivers for mouse and keyboard, input handler, console device and higher level console handler, a process specifically managing the console clipboard (other apps might handle it themselves), the clipboard handler, the clipboard device, a filesystem handler for wherever the clipboard was mapped, the underlying disk device - usually ramdisk but could be anything, and more depending on setup). That was to make latency predictable first and foremost, at the cost of throughput, but the overall model could be adapted.
But part of the challenge is to write applications this way without just ending up being bottlenecked on the message exchanges.
Even if you can make that cheap enough, we still have the problem of the vast number of tasks that are simply very hard to parallelise. For some of them splitting them up and spreading them out certainly could make things like pipelining processing help us cut latency when something is done repeatedly, but whatever we do, we will have big challenges ahead.
[1] https://www.parallella.org [2] http://www.adapteva.com/announcements/epiphany-v-a-1024-core...
The limit a decade ago was about Dennard scaling. Closely related but not the same as Moore's Law
I think we will keep seeing better CPU bench scores. There are more ways to increase performance then more cycles. For example parallelism.
Intel, AMD, ARM, etc could learn from supercomputers from 1970s/1980s era. They had to deal with heat problems and found solutions, look at e.g. Cray 2
Some applications would benefit a lot from higher single core performance, some applications would benefit from many cores on the same mainboard. For well know reasons (little competition) we are stuck with desktop 4 cores (and 2 on notebook even the i7) with little increased single core performance for years. Now that AMD comes with more competitive CPUs with a good price, Intel finally dusts of some years old designs from their basement and finally releases their first i7 notebook CPUs with more than 2 cores. So AMD and ARM CPU competition to Intel almost-monopoly is very good to bring fresh air to the stagnated desktop/notebook/server market.
Some applications would benefit a lot from higher single core performance, some applications would benefit from many cores on the same mainboard. For well know reasons (little competition) we are stuck with desktop 4 cores (and 2 on notebook even the i7) with little increased single core performance for years. Now that AMD comes with more competitive CPUs with a good price, Intel finally dusts of some years old designs from their basement and finally releases their first i7 notebook CPUs with more than 2 cores. So AMD and ARM CPU competition to Intel almost-monopoly is very good to bring fresh air to the stagnated desktop/notebook/server market.
Cray 2 was a cabinet-sized minicomputer. They "solved" the heat problems with airconditioning and fans.
The issues revolving around nano-meter scale heat bottlenecks is fundamentally different. You're smaller than airconditioners and fans.
The issues revolving around nano-meter scale heat bottlenecks is fundamentally different. You're smaller than airconditioners and fans.
> They "solved" the heat problems with airconditioning and fans.
Wrong. Read at least the related Wikipedia article. https://en.wikipedia.org/wiki/Cray-2
Wrong. Read at least the related Wikipedia article. https://en.wikipedia.org/wiki/Cray-2
Looks like an air conditioner to me. Its a liquid that absorbs heat, evaporates... while in gaseous form it is pumped to another location where it condenses and pumps heat out.
Yeah, its nothing more than a fancy air conditioner. http://www.energyquest.ca.gov/how_it_works/images/air_condit...
In any case: I'm curious why you think this cabinet hold any use with regard to nanometer scale engineering tasks:
https://upload.wikimedia.org/wikipedia/commons/4/49/1985-Cra...
There's a big difference between "cooling down a cabinet" and "cooling down a 10x10nm hotspot"
-----------
IBM's "liquid cooled chips" might be a potential solution: where water is pumped through channels on the die itself. (!!!). The water absorbs the heat directly from the die.
https://www.cnet.com/news/how-ibm-is-making-computers-more-l...
But the technological hurdles to accomplish this sort of task are massive! IBM's done it, but no one else has figured out how to do it. So its not a simple task by any stretch of the imagination.
Yeah, its nothing more than a fancy air conditioner. http://www.energyquest.ca.gov/how_it_works/images/air_condit...
In any case: I'm curious why you think this cabinet hold any use with regard to nanometer scale engineering tasks:
https://upload.wikimedia.org/wikipedia/commons/4/49/1985-Cra...
There's a big difference between "cooling down a cabinet" and "cooling down a 10x10nm hotspot"
-----------
IBM's "liquid cooled chips" might be a potential solution: where water is pumped through channels on the die itself. (!!!). The water absorbs the heat directly from the die.
https://www.cnet.com/news/how-ibm-is-making-computers-more-l...
But the technological hurdles to accomplish this sort of task are massive! IBM's done it, but no one else has figured out how to do it. So its not a simple task by any stretch of the imagination.
> Intel, AMD, ARM, etc could learn from supercomputers from 1970s/1980s era. They had to deal with heat problems and found solutions, look at e.g. Cray 2
You have to be more specific here to support such a claim.
You have to be more specific here to support such a claim.
Seymour Cray used to say that the biggest problems in supercomputing were the thickness of the mat and getting rid of the heat. The "mat" refers to the wiring on the backplane, which in those days was wire-wrapped. The Computer Museum in Mountain View has a Cray I in the lobby, and you can see its wiring mat easily.
Getting rid of the heat in the Cray I involved lots of copper with fluid channels, like the stuff overclockers use. The Cray 2 ran the whole CPU in a tank of inert fluorocarbon liquid. This was generally considered a pain. The idea comes back now and then. One Bitcoin mining farm in Japan ran submerged in coolant. Everybody else just used air cooling, sometimes in a cold climate.
Getting rid of the heat in the Cray I involved lots of copper with fluid channels, like the stuff overclockers use. The Cray 2 ran the whole CPU in a tank of inert fluorocarbon liquid. This was generally considered a pain. The idea comes back now and then. One Bitcoin mining farm in Japan ran submerged in coolant. Everybody else just used air cooling, sometimes in a cold climate.
> You have to
I have to do nothing. You could fire up Wikipedia or Google or Amazon...
Entire articles and books are written about Cray supercomputers and are waiting to be read by curious individuals.
For Cray 2, that's the Wikipedia article: https://en.wikipedia.org/wiki/Cray-2 it just gives an basic overview so don't jump to conclusions based on it. But it's worth to dive further in, really interesting topic.
I have to do nothing. You could fire up Wikipedia or Google or Amazon...
Entire articles and books are written about Cray supercomputers and are waiting to be read by curious individuals.
For Cray 2, that's the Wikipedia article: https://en.wikipedia.org/wiki/Cray-2 it just gives an basic overview so don't jump to conclusions based on it. But it's worth to dive further in, really interesting topic.
I am curious about heating and cooling, as I have built water cooling systems in PCs, but I am truly inexpert when it comes to industrial cooling. You are the one trying to make a point, and presumably know about some interesting problem and solution.
If I do a search I will start with no knowledge of Cray and no context to find this answer, even the wikipedia page is too general. If I find common fan and water cooling solutions I might not see why they are better because that information might be too subtle for me as a novice. If you don't provide it is unlikely to be found this discussion; this conversion and you will be intellectually poorer for it.
The onus truly is on you to provide interesting information in conversation when you talk.
If I do a search I will start with no knowledge of Cray and no context to find this answer, even the wikipedia page is too general. If I find common fan and water cooling solutions I might not see why they are better because that information might be too subtle for me as a novice. If you don't provide it is unlikely to be found this discussion; this conversion and you will be intellectually poorer for it.
The onus truly is on you to provide interesting information in conversation when you talk.
Moores law has been the driving force of chip development?
Prophet Moore predicted the future and now engineers start breaking the law?
Isn't it the other way around that Moore made an observation about some effect that arose naturally? The formula was then called Moores law and its extrapolation had great predictive power for a long time.
Similar effects occur all through industries when you start scaling things up. Quality will go up and cost per unit will go down. Often following a simple mathematical formula which describes the learning curve.
In many technologies there is something called maturity where the straight line in the diagram starts to bend and approaches a technical limit. Markets overcome this a few times by changing the technological approach of solving a problem to an approach that has a better limit. This makes the general trend continue for decades... until the point where the next technology is so expensive that noone can afford it anymore.
Thus far Silicon has won every round and chip manufacturing plants cost many billions of dollars.
Prophet Moore predicted the future and now engineers start breaking the law?
Isn't it the other way around that Moore made an observation about some effect that arose naturally? The formula was then called Moores law and its extrapolation had great predictive power for a long time.
Similar effects occur all through industries when you start scaling things up. Quality will go up and cost per unit will go down. Often following a simple mathematical formula which describes the learning curve.
In many technologies there is something called maturity where the straight line in the diagram starts to bend and approaches a technical limit. Markets overcome this a few times by changing the technological approach of solving a problem to an approach that has a better limit. This makes the general trend continue for decades... until the point where the next technology is so expensive that noone can afford it anymore.
Thus far Silicon has won every round and chip manufacturing plants cost many billions of dollars.
Moore's law started out purely observational, but over the years it became a driving force of its own. Chip manufacturer's performance is judged against Moore's law. Roadmaps and timelines are drafted with Moore's law in mind. Massive research investments are undertaken with the expectation that they will enable a company to keep pace with Moore's law.
Even if you're not doing chip design, anyone planning more than one chip product cycle into the future needs to take into account Moore's law. If you're building a hardware system or even a software project, ignoring Moore's law means that by the time you ship, your product might be cheaper than expected but also missing features that are now cost-effective.
Even if you're not doing chip design, anyone planning more than one chip product cycle into the future needs to take into account Moore's law. If you're building a hardware system or even a software project, ignoring Moore's law means that by the time you ship, your product might be cheaper than expected but also missing features that are now cost-effective.
Chip manufactures aren't going to be able to keep it up though. Look at all the problems getting a 10nm chip working, look at how those issues are going to get much worse at 7 and 3nm scales. Advances now seem more putting all the optimizations back in that they ignored in the quest for the physical bottom.
I think a key point that's ignored is that data movement is the new problem. For example, according to Lawrence Livermore National Laboratories, the cost of moving a 64-bit word 1mm ON CHIP on the 10nm projection is approximately equal to doing a 64-bit FLOP. And the cost of DRAM is outrageous... It's what's holding back exascale and will hold back general purpose compute as well.
Architectures MUST change radically to adapt to this or there can be no progress.
Architectures MUST change radically to adapt to this or there can be no progress.
> the cost of moving a 64-bit word 1mm ON CHIP on the 10nm projection is approximately equal to doing a 64-bit FLOP
Is this the cost in Joules or nanoseconds?
Is this the cost in Joules or nanoseconds?
Joules, but the cost of memory access in terms of speed has an even worse disparity.
This is just another law at work, namely the law of diminishing returns. At some point, each additional transistor that you add on a chip will increase its computational power less and less.
Any links? This would be interesting to read/watch more about
I wasn't able to find the exact slideshow, but here's something that gets the point across more or less.
Page 37 is what you're looking for.
https://fas.org/irp/agency/dod/jason/exascale.pdf
Page 37 is what you're looking for.
https://fas.org/irp/agency/dod/jason/exascale.pdf
> In 1975, Wilson was part of the team that developed the 6502
You can get a better summary of her early career from her computer history museum oral history interview: http://www.computerhistory.org/collections/catalog/102746190 - worth your time.
You can get a better summary of her early career from her computer history museum oral history interview: http://www.computerhistory.org/collections/catalog/102746190 - worth your time.
Fantastic read, thank you!
I imagine this will begin to put some pressure back to making things faster again as speed-ups that were previously expected fail to appear. (i.e. JS performance on mobile)
These days it's not a big deal to most developers, but I think over the next few years if there aren't major advances in speed we will want to get that extra battery life and speed out of our applications and devices. Independent Developers hopefully will have a good financial reason to do that, unlike today.
These days it's not a big deal to most developers, but I think over the next few years if there aren't major advances in speed we will want to get that extra battery life and speed out of our applications and devices. Independent Developers hopefully will have a good financial reason to do that, unlike today.
AI processor speedups will advance faster than Moore's law in the next 2-3 years, mostly due to lower precision (12/8/4 bits instead of 64/32 bits), massive parallelism, and a different programming paradigm. Google's TPU's for example are close to hardwired matrix multiplication. Maybe speedups for traditional scalar-oriented code matters less now.
Intel Lake Crest: "will enable training of neural networks at 100 times the performance on today’s GPUs, said Diane Bryant, executive vice president and general manager of Intel’s data center group"
https://venturebeat.com/2016/11/17/intel-will-test-nervanas-...
Google TPU: "The TPU...used 8-bit integer math...process 92 TOPS" (trillion operations per second)
https://www.nextplatform.com/2017/04/05/first-depth-look-goo...
Generally:
http://www.moorinsightsstrategy.com/what-to-expect-in-2017-f...
Intel Lake Crest: "will enable training of neural networks at 100 times the performance on today’s GPUs, said Diane Bryant, executive vice president and general manager of Intel’s data center group"
https://venturebeat.com/2016/11/17/intel-will-test-nervanas-...
Google TPU: "The TPU...used 8-bit integer math...process 92 TOPS" (trillion operations per second)
https://www.nextplatform.com/2017/04/05/first-depth-look-goo...
Generally:
http://www.moorinsightsstrategy.com/what-to-expect-in-2017-f...
I really don't think so. The current graphic cards are heading torward the same issues Intel is doing. It's getting longer for improvement in GPUs to occur .
GPUs are more complex than what's needed for AI, take a close look at Google TPU for example.
The TPU is used in inference, not in training, GPUs can be used for both.
https://www.extremetech.com/computing/247199-googles-dedicat...
https://www.extremetech.com/computing/247199-googles-dedicat...
Intels claims of 100/1000x preformance increases are becomming less than credible.
They promised the same sorts of things with larabee and thunderbolt and Xpoint.
All have been massive underpreforming dissapointments.
They promised the same sorts of things with larabee and thunderbolt and Xpoint.
All have been massive underpreforming dissapointments.
The death of Moore's Law will have as much to do with CFOs deciding that the investment isn't worth the return as it will with technological innovation. When Intel decided to layoff 12k last year, it seemed like the writing was on the wall. ITRS seemed to think so, anyway:
https://www.hpcwire.com/2016/07/28/transistors-wont-shrink-b...
Going from Tick-Tock to Tick-Tock-Tweak... and this year to Tick-Tock-Tweak-Tuck the fourth year of 14nm (still as compact as other companies 10nm) makes the slowdown palpable. Perhaps they will manage a 2.7x shrink at their "10nm node" with or without EUV, but it's not the straight scaling of yesteryear.
https://www.hpcwire.com/2016/07/28/transistors-wont-shrink-b...
Going from Tick-Tock to Tick-Tock-Tweak... and this year to Tick-Tock-Tweak-Tuck the fourth year of 14nm (still as compact as other companies 10nm) makes the slowdown palpable. Perhaps they will manage a 2.7x shrink at their "10nm node" with or without EUV, but it's not the straight scaling of yesteryear.
Yeah. There are plenty of distress signs in the semiconductor ecosystem. Toshiba selling due to inability to invest, Mentor going to Siemens and Intel buying small tooling companies who are unable to sustain investment due to their customers having merged or gone out of business. It happens across the whole value chain. A few vertical integrated businesses are able to keep up for the time being. Whether for one, two or three generations remains to be seen.
It's partially that, but EUV litho is REALLY hard to make at a low enough resolution.
I'm not sure what you mean. EUV at 13nm (Extreme UV, after marketing with the name X-Ray Lithography failed) is much easier to make work at 10nm than the current multi-patterned immersion technology based on 193nm ArF excimer.
http://www.anandtech.com/show/10097/euv-lithography-makes-go...
The problem with EUV is that the source power (laser excitation of plasma) is too low, making exposure times too long for the expense of the equipment.
http://www.anandtech.com/show/10097/euv-lithography-makes-go...
The problem with EUV is that the source power (laser excitation of plasma) is too low, making exposure times too long for the expense of the equipment.
"Shot noise" is a problem too, due to the high energy of the EUV photons.
Yes that's true, but shot noise is a real problem.
Yes, shot noise... secondary electrons, resist issues, mask issues are all real. Similar issues come up for immersion at these scales. It's no panacea (and hasn't even reached tact time parity), but nothing is at this point. What is amazing is that the investment in EUV has been going on for decades and still hasn't reach production.
If they could run the EUV sources at 4 times their current power, there would be huge increases in equipment sales and conversely exposure and mask complexity would decrease substantially. Increased exposure dose could deal with some of the shot noise effects (only 3% at 10nm so less than 8% ITRS spec?).
We would also probably see equipment free up to allow 14/20/28nm litho costs go down. So it's a win-win.
If they could run the EUV sources at 4 times their current power, there would be huge increases in equipment sales and conversely exposure and mask complexity would decrease substantially. Increased exposure dose could deal with some of the shot noise effects (only 3% at 10nm so less than 8% ITRS spec?).
We would also probably see equipment free up to allow 14/20/28nm litho costs go down. So it's a win-win.
I disagree about the limitations of software parallelism. The article is correct that many existing algorithms like ray tracing or apps like web rendering have inherent limits to parallelization, but there exist a large number of "embarrassingly parallel" things that simply are not done on small PCs and phones right now because they're too costly. This includes things like neural networks, genetic algorithms, all kinds of optimization algorithms, etc.
This article is from 2007 so it predates the AI renaissance. Lots of AI, ML, and optimization stuff can happily eat as many cores as you want to throw at it.
Then there's the multitasking angle. On a desktop at least I often run dozens of applications, developer VMS, etc. I could definitely use 20 cores in a desktop/laptop right now. We have tests that easily max out a 24 core server that I'd love to run on my own box.
This article is from 2007 so it predates the AI renaissance. Lots of AI, ML, and optimization stuff can happily eat as many cores as you want to throw at it.
Then there's the multitasking angle. On a desktop at least I often run dozens of applications, developer VMS, etc. I could definitely use 20 cores in a desktop/laptop right now. We have tests that easily max out a 24 core server that I'd love to run on my own box.
On the other hand, many computer functions have reached the "good enough" level. A normal laptop can handle web browsing and document editing just fine. Resolution over Retina level and digital cameras over 10 megapixels are not necessary. Also, sound fidelity over 44khz is not useful. Video over 4K also is on a diminishing curve of returns. We have little extra improvement to get from many domains. Where do you think more processing power would add a large benefit?
>Even for highly parallel workloads like ray tracing, the performance increase levels off at about 20 times. “No matter how many processors I apply, ray tracing ain’t going to go any faster than 20 times faster,”
What? That's just not true. Matrix multiplication is one such embarrassingly parallel workload that can go much faster than 20 times. Ray tracing very probably too.
What? That's just not true. Matrix multiplication is one such embarrassingly parallel workload that can go much faster than 20 times. Ray tracing very probably too.
This can simple not be true: proof: take 2 computers render in parallel, combine images at the end when happy with the result. The combined images will look better. The 2 computers shared no resources. As such, ray-tracing scales.
Luxrender for example has a problem here: all threads are writing to the same output buffer, causing bottlenecks and non perfect scaling. (Might be corrected by now.) The advise then was: run 2 or more Luxrenders, and combine the output image (luxrenders flm file).
Luxrender for example has a problem here: all threads are writing to the same output buffer, causing bottlenecks and non perfect scaling. (Might be corrected by now.) The advise then was: run 2 or more Luxrenders, and combine the output image (luxrenders flm file).
I suspect Wilson was saying "Since 5% of the runtime of the raytracing algorithm cannot be sped up through parallelism, even if the time needed to run the other 95% were reduced to zero due to parallelism (or some other magic), the speedup of raytracing could never exceed 100/(100-95), or 20X."
In essence, Amdahl's Law trumps Moore's Law.
In essence, Amdahl's Law trumps Moore's Law.
And that's true with some workloads, and maybe some systems that use raytracing, but not raytracing itself. The only overhead is combining the final data from each processor, and that's log(n) in the number of processors with a very small constant. A system with a million independent processors can raytrace very nearly a million times faster.
Moore's Law trumps Amdahl's Law when you decide to simply solve two problems at the same time.
Instead of a 19X speedup on rendering, you get an 18X speedup on both rendering, physics, and AI, and gain some extra responsivity on the mean-time.
Instead of a 19X speedup on rendering, you get an 18X speedup on both rendering, physics, and AI, and gain some extra responsivity on the mean-time.
If one believes Ray Kurzweil(among others), this is just a phase shift where the focus of change moves away from this technology towards a new one. But then the question is: which one? We do have some options floating around.
Memory did not go faster so much. You can cram bazillions of transistors on a chip, even do clever tricks to fix power consumption/dissipation...but no trick will feed them data fast enough.
Yup, we won't be able to keep shrinking MOSFETs forever. There's like to be an interregnum of some sort before a new computing substrate is developed that give us substantially faster gates. And possibly fewer but higher frequency gates at first, which would be interesting.
In the mean time we might see a new golden age of computer architecture where the only way to increase performance is to question assumptions about how we design computers.
In the mean time we might see a new golden age of computer architecture where the only way to increase performance is to question assumptions about how we design computers.
We also always tend to neglect the equally important counterpart to Moore's Law,Dennard scaling. Dennard scaling is on its deathbed, and has been plateauing from around 40/28nm. Since power consumption is now the problem for everyone, including supercomputers, this problem will compound the almost impossible to solve data movement wail m
Very sad to see this ending.
Interesting and relevant paper on the end of Moore's Law: ftp://ftp.cs.utexas.edu/pub/dburger/papers/ISCA11.pdf
Is this even news?
I have heard the dramatic "Oh no Moore's law is coming to an end" a dozen times during computer engineering courses. Professors are usually slow to adapt new information and it is already a couple years ago that I took those courses. I think that the transistor count has been slowing down for about a decade already.
I have heard the dramatic "Oh no Moore's law is coming to an end" a dozen times during computer engineering courses. Professors are usually slow to adapt new information and it is already a couple years ago that I took those courses. I think that the transistor count has been slowing down for about a decade already.
The article says that 28nm will dominate for another decade, even though 14nm fabs exist. Having to use extreme ultraviolet (really soft X-rays) for lithography runs costs way up. EUV "light sources" are insanely complex, involving heating falling droplets of metal to plasma levels with lasers. It's amazing that works as a production technology. The equipment looks like something from a high energy physics lab.
It's interesting that we hit the limit of photons before the limits of atoms or electrons.
Another problem with all this downsizing is electromigration. Every once in a while, an atom gets pulled out of position by the electric field across a gap. Higher temperatures make it worse. Narrower wires make it more of a problem. This is now a major reason ICs wear out in use.
Getting rid of the heat is another problem. High performance CPUs are already cooling-limited. This is also why 3D IC schemes aren't too useful for active components like CPUs. Getting heat out of the middle of the stack is hard. Memory can be stacked, if it's not used too hard.
There's no problem making lots of CPUs on a chip, if the application can use them. Things look better server-side; you can use vast numbers of CPUs in a server farm, but it's hard to see what 20 or 100 CPUs would do for a laptop.
Drastically different architectures may help on specialized problems. GPUs have turned out to be more generally useful than expected. There will probably be "deep learning" ICs; that's a problem where the basic operation is simple and there's massive parallelism.
For ordinary CPU power per CPU, we're close to done.