There are three main limits, and several secondary ones.
The big one is heat. As densities go up, so do power consumption and heat dissipation for active cells. Inactive cells are OK, which is why the highest density devices are now flash memories. That doesn't help CPUs.
The next is fab cost. As someone else pointed out, state of the art fabs cost billions now, and there are fewer ones with each generation.
Finally, of course, sizes are getting close to the atomic level.
Secondary limits include electromigration (the atoms won't stay where you put them as they're pulled on by electric fields) and even X-rays not being short enough for mask etching.
Heat is the biggest problem. CPUs aren't that big; you can fit a thousand in a shoebox if you can cool them. The Bitcoin ASIC business is a worst case. Those devices need no external memory and very little I/O, but most of the gates toggle on every cycle. Mining farms are now located in cold climates near cheap power stations.
You realize having to write better code is a bad thing, right? It makes writing software more expensive, and decreases the supply of people who can do it.
Also, people aren't going to start valuing craftmanship because you added more constraints. Adding a speed constraint won't make the pile of hacks upon hacks smaller, it will add a layer of speed hacks. It won't fundamentally rewrite the incentives for software, where companies that do the minimum amount of work to hit an acceptable speed are rewarded. It just culls companies naive enough to think they could write something elegant or concise.
> It makes writing software more expensive, and decreases the supply of people who can do it.
That sucks for business types, but this has a real upside for professional programmers. Despite propaganda, salaries are based on supply/demand, not impact.
Zero cost abstractions are a great thing. Rust is working towards this. Readability and speed is a great goal and there is no reason to believe it cannot be achieved.
Impossible, entry level for CS and programming is drastically falling down every year, languages that don't require any CS knowledge or thinking become more and more popular. During my undergraduate studies no one told me that something like CPU cache or branch prediction exists, we were just told C#, Java, JS and PHP are used in the industry so learn it and you will have "a job". Some students did their MP in PHP, JS where you could login as red status bar (HTML injection in login). We were not told about vagrant or static code analysis. I had to learn in myself from reddit and contributions to OSS. People who call them self senior JS developers don't know how to solve basic algorithmic problems.
Maybe this is the source of the recurrent discussions here, and elsewhere, about how formal CS education doesn't matter (something I wholeheartedly disagree).
Universities have always been under fire to provide courses "better suited" for market needs and it seems to me that they've been slowly caving in during the last decade or so. This, of course, probably varies a lot between country and even between universities in the same country.
The fact is: university courses that degenerate into professional training courses end up providing little value. Timeless CS principles are abandoned for marketable high-level skills that are obsolete even before students finish their studies, and that help nothing when the market itself changes (or needs to change).
I see Europe's Bologna process as a perfect example of this. It was supposed to make higher education comparable between EU countries but instead now provides an excuse for shorter and shallower courses, comparable only because they don't go any further than the lowest common denominator.
What you say is really evident in some circles: a magical view of computing platforms and a complete ignorance of hardware details critical for software performance. There is a blind faith on compilers/interpreters to somehow extract maximum performance from the hardware in the face of wastefulness.
As anecdotal evidence, I've more than once had to convince people that allocating new objects by the millions (in the JVM) has a real CPU performance cost. The usual response is that the application isn't limited by memory and the time required by the garbage collector is negligible, thinking nothing about cache locality and how memory access is now a major bottleneck for modern CPUs.
I don't know that I agree... people can learn in many different ways, and don't always need to deal with different aspects. If all I want to do is build bird houses, do I need to learn everything a structural engineer has to learn to build sky scrapers?
That said, had a similar issue with logic in a simulation software where each virtual unit was its' own OO based object, with it's own threads for events... could only run about 4 simultaneous simulations on a server, and it still would bottleneck (GC was horrible). change it to a single event-loop that signaled each unit, and most of the concurrency issues went away. Streamlined the message passing (more functional approach) and memory usage dropped a lot... couldn't convince the manager to switch away from an SQL backend, which was the final bottleneck (normalized data structures), as it was then fast enough.
Had another instance where a configuration table from a database was loaded into memory (for performance), but then was kept in memory as a DataTable, with text based queries for each access for each key, that happened over a thousand times in a single web request (logins were taking too long)... Changed it to a HashTable, and lo and behold, concurrency was no longer a problem... similar issues with not understanding how static variables worked in a multithreaded application... OO ftw again (sarcasm).
"If all I want to do is build bird houses, do I need to learn everything a structural engineer has to learn to build sky scrapers?"
Of course not. People should have the choice on how and what they want to learn. I just disagree when choice is turned into equivalence (i.e. formal education providing no value over self-learning / disguising knowledge to build bird houses as knowledge to build skyscrapers).
In some cases (some people) it may not actually matter, but in the general case, looks like it does.
I will say that it depends on the person... I've taken from learning how to do simple scripts in the 80's/90's and actually done reading on lower-level CS, and although I don't write C/C++ day to day, I do understand the concepts. And while I don't have to think about such things.. understanding memory constraints and how caching and process swaps work in the CPU has come in useful even for higher level language projects.
But isn't that why we're supposed to have "Junior" and "Senior" level positions? I think that what software development really needs is a loosely structured guild system where you gain rank not by attrition or seniority but by reputation, where you gain/lose reputation based on who you back for seniority and how well they do. It seems that beyond CS education, it's a constant learning process. You cannot make a career only with what you learn getting a degree in CS.
That's difficult to achive without the reputation system being overrun by politics sooner rather than later, I guess.
It's true that a degree in CS doesn't make a career, and that it's mostly a constant learning process. After a while the difference between having a degree or not having one is difficult to measure and junior/senior levels become defined by experience. But everything else being equal, the person with the degree will have forgotten a lot that the person without the degree wasn't exposed to in the first place. Many people will be exceptions to this, but I'm just talking about the general rule here.
Once you enter an organization, you build reputation there. This is the only thing that matters. To transfer this reputation between organizations, the organizations themselves must recognize the transfer (a form of trust). When you have long and convoluted interview processes, it means there is no such trust. The organization you are trying to join is basically starting from scratch in evaluating you skills, disregarding infomation that says that even if you can't balance a binary tree now, you once did and so can do it again if required.
University degrees are supposed to provide this information. They provide knowledge but also provide a path that is known to be difficult and with a known level of "reputation" once completed. Experience alone cannot possibly provide this, because work at company A says litte to company B if the inner workings of A is an unknown quantity to B.
This is the theory at least. If universities aren't doing they work properly, this whole system collapses.
I don't agree with your perspective of Europe's Bologna. Universities don't need an European agreement to create shorter and shallower courses, in fact, Bologna doesn't impose any kind of restrictions on the kind of courses the universities have.
And Bologna helps a lot with your education, by making higher education comparable between EU countries, you can easily apply for student exchange programs and study subjects that aren't approached by your home university.
I studied in one of the best engineering university of Portugal and I studied for one semester in Sweden and although both universities were under the Bologna agreement, I could notice differences in both systems.
The only thing that Bologna imposes in universities is how many hours of effort is 1 course credit (ECTS). Course content, organization and etc, is up to each university.
Before the Bologna process, engineering and CS degrees in Portugal used to be 5 year courses, minimum. After the Bologna process, curricula were modified so that courses could have a 3 year minimum.
This, by itself, isn't a bad thing.
However, the market perception is that these 3 year courses give the same level of qualification as the previous 5 year courses. It doesn't help that the name of the degree has been made the same on purpose ("licenciatura"). "They just removed useless stuff," they say.
This feeds back into students as "no need to go any further." Once they have reached the degree that the market recognizes (the "licenciatura") there isn't much incentive to continue for another 2 years to get a masters degree (btw, in the previous system a masters degree was 7 years).
Universities have to handle this somehow, and they do it by actually "removing useless stuff" from the 3 year curriculum thus reinforcing market perception and actually putting themselves on course to become training schools instead of universities.
These arguments are pretty specific to the portuguese case, and elsewhere things are bound to have been different but with the same general outcome. The general argument is this: solving the comparability problem between EU countries went too far and breached the universities' ability to resist outside influence (mainly political).
PS: The ECTS system is deeply flawed exactly because it is based on "hours of effort." Not only bacause that's a subjective measure on its own, but mainly because "effort" does not directly correlate to actual learning. A course may have very work-intensive assignments for very little knowledge.
Your comment and the parent comment aren't incompatible. Increasing the size of the software industry will naturally result in much greater specialization, with high-skill folks solving the hardest problems and farming out the easier stuff to low-skill people. Likewise, in the early days everyone needed to know how to fix most things in their car, and car mechanics had to be real experts. Now most car driver can't change their oil, car mechanics are following instructions given to them by the car's computer without much idea of how those decisions get made, but inside car companies there are guys with deep insight about how to electronically balance your engine.
I agree. I picked up JavaScript recently (I'm an embedded systems and firmware guy, so gimme a break!), and decided to play around with designing a basic game. Using parts off of the shelf (bootstrap, parse, and google's APIs) I could build a very pretty, responsive thing that worked well on a variety of devices.
While doing this, I was fumbling around from tutorial to tutorial, figuring out what's what (I still mis-type "backbone" and "bootstrap"). Reading through the questions that others are asking on stackoverflow, I saw a recurrent pattern. Someone would ask "How do I X?" Someone would answer "You do this, this, then that," explaining fairly-articulately the correct answer. A reply to that would be "I don't get it. Can you post a fiddle?" Sometimes inside of those, you'd see (what I think) is a mis-use of a framework. It would work, but either dragged an entire framework into the picture, or caused a tremendous amount of work to happen, when there would usually be a much simpler solution (i.e. do I -always- have to use jQuery?).
I feel like the entry level of programmer might need to change into a different title. "Software tradesman?" I'd describe these as people that know how to assemble a list of components into a working whole. They can replicate a pattern, filling in blanks where appropriate, but can't nip / tuck to change it, and certainly can't design and create a whole -new- component.
Small aside, getting rid of jQuery is kind of hard... I'm half surprised that no browser has taken the core of jQuery and simply integrated its' usage patterns in the browser at this point (considering everything else added to the DOM).
Dealing with the DOM isn't nearly has hard as it has/had been in the past, but it's still a bit more complex than jQuery's API... You can start with document.querySelector*, but then if you need an array, you need Array.from the results, then you can each/map/reduce until your heart's content... event binding is still quite a bit more verbose as well. Not to mention unbinding/cleanup when adding/removing nodes.
In the end, half the time I check "is jQuery in the project already" then I'll use it. More often than not, it is... that is except in "enterprise" projects where "enterprise" architects and the minions of developers have managed to introduce 3-4 different copies of varying old/ancient versions of jQuery and no idea which one is actually loaded. Because it's "just the front end" and have no concept/concern for actual load/performance... don't think about capturing state properly, and get weird behavioral patterns as a result.
Sorry for the rant, it just irks me that people are so dismissive of the front end or capability that the web offers because much of it is so easy to get results. On another note, if you get more into it, do yourself a favor and avoid Angular.
I guess the 3-4 copies of jQuery are my point; that's generally indicative of a misunderstanding of how things work.
Taking my own learning as an example, I want to build a single-page application, so I decided that I needed a framework to manage it, since that's what all the cool kids were doing. While sipping on a frosty beverage, I was comparing Backbone and Angular, and then realized that Parse (which I'd already decided to use) built their JS API on top of backbone. That quickly simplified things for me, but I still see people that are trying to bolt together angular and parse.
I see so many "oh just do it with jquery" comments on forums.. when in reality, 9 times out of 10, you just need some simple one-off function from it.. you end up loading some massive script to run 2 functions... oh wait, is that why compilers exist? :-) really what we need is a way to get jquery to extract out just the functions you want in a standalone way...
Please let us know which university that was, so others can avoid it. I'm glad you managed to teach yourself these important concepts despite that. I fear that others won't have been as go-ahead as you, and are instead writing the sort of crappy Javascript that brings my browser to its knees on certain websites, or makes my 6 core 64 bit phone run really slowly.
I took CS classes back in the early 90s and again just recently. Back in the 90s, I remember learning about CPU registers; text, stack, and heap memory; pointers; algorithms; etc. The classes I've taken recently were focused on language syntax; REPLs; IDEs; and frameworks. It seems there has definitely been a shift towards the simple during the last 25 years.
It's amazing how slow certain apps are, for example, on smartphones and how fine people are with it. Things that worked near-instantaneous on a desktop PC 15 years ago now take 5 seconds to load despite the hardware being way faster.
One of the reasons why I prefer to use "cloud" tools instead of LibreOffice is LibreOffice being slow...
Xcode on the MacMini I use to work is just terrible, it is SLOOOOOOOOOOOOW.
I wish I could code for iPhone with TurboC, the thing just worked, no loading time, if I hit a button, it do what I want instantly.
Games are also getting notoriously bad, I've been seeing 2D games, with no particularly important special effects, get extremely slow on my computer (that can run some very beautiful older 3D games easily), Starbound is a very bad offender at this.
But the one that pissed me off, is Epic Games launcher... Shadow Complex is free in december for PC, to get it you install Epic Games launcher, that then downloads and installs it.
My gaming machine is old, and has some parts of it failing, and playing shadow complex tipped it over some edge and now it is overheating easily... at least I thought it was shadow complex fault, I eventually learned it was the launcher's fault, if I close everything and leave only the Epic Launcher open, it uses 100% of my GPU, and make its temperature shoot from 56C to 92C, it is just absurd... it does not even have any 3D on it, I have no idea why it uses the GPU, and why it needs that much GPU power!
Xcode is extremely I/O bound. When it's not compiling, it's indexing. An SSD helps it a lot. (Which isn't to say Xcode doesn't have its problems, including speed. Just that it can be improved with better hardware.)
Xcode is extremely slow even for operations that perform no IO at all, like code completion, or printing a variable in the debugger. (Seriously, I've had it take ten seconds to perform 'print foo', and not as a one-off thing either.)
Yeah, I've seen that, too. My experience has been that it takes several seconds to open the file or to switch back to it from another file, but once it's opened, I don't find editing it to be slow.
Yeah, the debugger one I don't get at all. I don't see the same problems in lldb on the command-line. In the past (when it was using gdb) I was told it was due to the data formatters. I would turn them off and the problem would go away, but I no longer see a way to turn them off.
> I wish I could code for iPhone with TurboC, the thing just worked, no loading time, if I hit a button, it do what I want instantly.
I haven't used turboc in over 20 years, but I don't recall it doing things like code completion and refactoring and all the other stuff one expects from a modern ide. (this is not to defend xcode)
based on historical evidence, a dedicated chip for executing javascript will be created before the industry makes a concerted effort to find a better tool.
You're probably joking, but the "we need CPUs that are optimized for our high-level languages"-argument has been raised again and again in all seriousness in the past, without anyone ever showing a convincing way to speed up Javascript, Python, etc. in hardware. Fact is, chasing pointers through small objects or looking up methods in hash tables is very cache-unfriendly, and memory latency is the bottleneck for many computational tasks today.
Instead, we should work on improved languages that provide better compromises between performance and convenience. Rust, for example, is a good step in this direction.
There's http://www.azulsystems.com/products/vega/processor, which is a CPU with special GC instructions, created by the same company as one of the most sophisticated garbage collectors. Apparently they thought they could speed things up with specialized hardware. Not sure what the performance looks like in practice, but it is interesting that it exists...
Azul had/has some interesting technology. (They're still around but just do software now.) I had some conversations on this topic broadly at a conference I was speaking at a month or so ago which had more hardware/software overlap than is typical. IMO, we're unlikely to come up with anything else in the near-term that delivered the kind of scaling CMOS process technology did. As a result, it's at least possible that we'll see specialized hardware make more sense in a world where "Moore's Law" won't let general purpose x86 chips just hit the same performance level in a couple of years.
Well, whatever language you want to run, processors that are good for cache unfriendly tasks would be huge for logical AI, data mining, some kinds of image processing, and possibly a lot of other tasks.
As dies get bigger, there's no law of nature saying that CPU power must be concentrated far from memory.
> As dies get bigger, there's no law of nature saying that CPU power must be concentrated far from memory.
Actually, there is. The main reason why the L1 cache is so small, is that a larger cache would take more cycles to access. The L2 cache is allowed to have a higher latency, so the electrical signals have more time to propagate through a physically larger area.
3D stacked dies alleviate this problem, and the trend goes towards putting several dies side-by-side in a single package (a chip), enabling lower latencies, higher throughput, and less power consumption.
I just wish the human race would stop pretending to know what the future may or may not hold.
You would think that with our recorded history, people would be smart enough to shut up about the "limitations of the future". There is not a single person alive today who knows what technology will look like in 10 years, let alone 100 or 1000+. All it takes is a single new discovery from a single person to completely change our understanding of what is possible with technology - or any other aspect of our lives.
The blatant arrogance with which people pretend to know what the future holds is infuriating. Why do so many find it so difficult to admit that we know an infinitesimal portion of total knowledge of the universe? We only recently discovered electricity. Computing is still in its infancy. A computer from the future - if they are even called that anymore - may be directly comparable to what we have today. Or the technology may change so much that the two devices are not even recognizable as being related.
People need to stop telling me that it's impossible for technology to scale as much in the next 30 years as it has in the past 30. What looks like a technological ceiling today could evaporate at any time.
Why does the human race insist on believing that the knowledge we have gained so far is "all there is to know", until proven otherwise? It strikes me that one has to be quite literally an imbecile to not understand that the future will unfurl much that we cannot even fathom today. This insistence that the world of computing 50 years from now must somehow be built on the shoulders of existing technology... it's absurd to be that closed-minded.
There a physical barriers, say, conservation of energy (or for mechanical systems conservation of linear and angular momentum), non-decreasing entropy etc. If I were a physicist I could tell you a lot more of these invariants (say from quantum physics). We surely don't know what technology the future will have, but I would bet that at least for the next 50 years there will be no fundamental breakthrough that both changes our understanding of such laws of nature and is already at this timeframe available to be implemented in technology (the last time that such a breakthrough occured was theory/ies of relativity and quantum physics - both at the beginning of the 20th century).
So I might not know what the future is like, but we can surely make lots of scenarios highly unlikely.
> There is not a single person alive today who knows what technology will look like in 10 years
Agreed, nobody knows what's going to happen in the future, however...
>Computing is still in its infancy. A computer from the future - if they are even called that anymore - may be directly comparable to what we have today. Or the technology may change so much that the two devices are not even recognizable as being related.
... you should remember that 'nobody' also includes you. For computers to keep getting faster we'd need something faster than a MOSFET to build our computers on.
The fact that it hasn't been discovered in 90 years doesn't mean it's not going to be discovered ever, but it also doesn't mean it's bound to be discovered soon because of the unstoppable kurtzweilian march of progress.
Since we can't predict future discoveries because of the law of total expectations the best we can do is try to describe what the future looks like from here.
The most important new code is massively parallel. Using GPUs today but surely new architectures soon. The human brain is highly parallel, so no surprise there.
Look how tiny the source code to Deepmind's general Atari player. It's a completely different model from traditional development:
As far as where to innovate, how about engineering wifi/3G/LTE to use less than 700mW of power?
The smartphone is the first universal tech for mankind, and CPU is not the bottleneck there, it's screens & radios, all batteries being equal of course.
Purchasing a company is not necessarily "losing money" unless no synergy is possible between core competences. But in fact, Altera/Intel's respective core competences suggest programmable logic devices next to high-speed multi-core CPUs may be one way to keep Moore's law going (See http://www.eejournal.com/archives/articles/20140624-intel/ for example).
> Intel is also catering to the market for supercomputers for scientific use. Intel's Knight's Corner ... a small niche market ... RAM speed is now often a serious bottleneck.
Many of the scientific supercomputing applications are migrating to GPU workloads with OpenCL and CUDA. One enormous benefit of making this migration is the extremely fast memory that's available on GPUs.
> A likely development will be to put the RAM memory on the same chip as the CPU (or at least in the same housing) in order to decrease the distances for data transmission.
I've been waiting for this for 5 years, I don't know why it hasn't happened already.
- Optimized clock speeds, layouts, improved connectivity (i.e. increased number of RAM channels)
-- Reduced latency
-- Increased bandwidth
- Would there even be a need for an MMU?
-- CPUs wouldn't need to work with a variety of RAM types
-- i.e. Less complexity, fewer points of failure
The only cons:
- RAM size would not be configurable
Meanwhile, for better or worse, the majority of consumers can't re-configure their own RAM (Laptops/Smartphones), or on a desktop they don't know how. Businesses would either buy beefy hardware that suited their constraints or spend money on custom configurations. So this con only really effects hobbyists.
Given that RAM is relatively simple, I wouldn't have expected yields to be such an issue. Also, since the marginal cost of a CPU is relatively low, I figured again, it wouldn't be a large hit to Intel's bottom line to overcome the yields or to give out new chips through warranty.
Remember that for buyers, RAM and CPUs are marked up significantly. A combined CPU RAM unit, would be justified to have increased price over just a CPU. As long as CPU-RAM Unit cost <= CPU + RAM, buyers wouldn't mind and society would end up better as a whole. Potentially making it worthwhile for Intel, regardless of loss in yield.
I am not very educated on the subject though, so I'll defer to your knowledge on it, and agree.
I read this on a $149 Chromebook wondering why do I need a faster processor? Sure the servers this ARM processor powered computer is connecting with in the cloud are powered by Intel processors but the optimizations at this point are in the software.
Fortunately, not everything is on the Web yet, and not everything interesting to do with computers is done on-line.
I read this wondering why the CPU prices aren't dropping - my i5 costs as much today as it did exactly 4 years ago, when I bought it - and I'm sad about this, because I could use a faster CPU for Kerbal Space Program, but I'm not going to pay third of a new computer's worth for a marginal improvement in clock speed.
It's just in desktop i5 segment. Intel threw more cores to Xeons and much higher clocks at low TDP CPUs, but that means nothing for desktop user. IPC only improved by about 25% during last few generations. Also AMD has nothing competetive in that segment.
Yes (it is hard). Since those "other" are not that many -- most people just do web, text processing, Excel, mails, gaming etc, for which cpu power is plenty.
Now, even if we take some specialized tasks that need more CPU (but are niche anyway):
- For image processing, we had Photoshop doing wonders since at least 2000. And with SSDs, we can view and edit 30+ MP images today faster than we could 8K images back in 2000 (and on 4K displays nowadays). We can very much cover all things web and print just fine.
- For video processing, a fast latest box can edit several streams of 4K with live filters. That's beyond what $200,000 professional boxes could do in the early nineties.
- For audio processing, a MacBook Pro i7 can run more audio channels and effects than what the consoles used for Thriller or The Wall had in million dollar professional studios.
We also need to understand the concept of diminishing returns. E.g. It's not like having an NLE rendering time down from 2 hours to 1 minute will enable us to make more movies. It will just save some editing studios and amateurs some time. Other processes involved in movie making (like just setting the lights appropriately for a shoot) trump this "optimization" many times over.
So it's not like people "need" faster processors. It's more like they would be "nice to have".
Now, for things like HPC for research etc, could indeed use faster processors -- but that's an even more niche market.
Not until content creation tools get smarter. When your level is made of simple tiles in 2D top-down perspective, you can have large levels with lots of sprites, but when each character has to be a fully rigged 3D model and each tree rather than being an 8x8 pixel smudge is instead a fully 3D physical object with leaves that respond realistically to wind... Well, it's hard to make them by hand.
>The faster computers get, the more interesting games can get.
I've found the opposite. The faster computers get, the more games are all about BS graphics and nice explosions. Back in my day we had real interesting adventure games, now get off my lawn.
Considering that it's quite inefficient and written in Java, it might very well be. Especially graphics wise, it's nothing that mid to late nineties GPUs couldn't handle.
Minecraft was memory-bound and bandwidth-bound such that it only really became possible in the late 2000's. A typical PC in 2000 would have, if generous, 128 or 256 megabytes of RAM. A typical connection, if any, would be dial up, with some ADSL and ISDN folks. Minecraft worlds, on the other hand, easily run into the gigabytes. Not to mention that all of its word of mouth came from popular Youtube videos.
You can definitely find examples of earlier voxel renderers that are also more efficient than Minecraft(e.g. Ken Silverman's VOXLAP), but memory limits and networking gaps would remain real and intractable, limiting its potential popularity.
It still takes a good few minutes to compile my current project at work (c++ compiles slowly), I could definitely use a 100x improvement there to bring it down to a couple seconds (no, I don't often need to compile it all from scratch but I would still pay good money for such an improvement).
How about all the industries like HFT or AdTech? You mentioned yourself research, there is a dire need for computing power (and I don't think it's that much of a niche).
Don't you think all these machine learning oriented start-up would like more CPU? How about big data platform?
It's very narrow minded to think that the only market is people using their laptop in their home office.
>How about all the industries like HFT or AdTech? You mentioned yourself research, there is a dire need for computing power (and I don't think it's that much of a niche). Don't you think all these machine learning oriented start-up would like more CPU? How about big data platform?
I don't think society would have any serious issues, in fact we might just be better off, without more efficient HFT and big data.
In fact, I'd ask for more regulated and slower-frequency trading, and smarter (rather than "big") data. And especially when it comes to surveillance and consumer behavior analysis (for ads, etc.), the less data those scumbags get, the better.
That there is a market doesn't mean there is a need. If HFT were forced into millisecond processing regimes instead of microsecond, what would be the impact to anyone? It wouldn't even affect the HFT guys as long as their competitors were likewise limited.
Bill gates (supposedly) asserted that no one would ever need more than 640K of RAM. Sometimes it's hard to understand the need for newer tech until you have it.
I think Akka is sort of heading in the right direction in its ubiquitous language. Akka talks about itself in terms of solving the "distribution problem" - not necessarily across machines but machines OR cores. It talks about "location transparency" as a first principle meaning that an actor/worker that processes a message can be either on another CPU or another physical machine and the location of that actor is transparent from the perspective of the code - it's a deployment/configuration concern.
It's convenient that multicore utilization is a scale problem at the same that utilizing networked compute resources (ie in the cloud) is scale problem resources because we might be able to treat them as similar problems. Yes the network introduces some other unique qualities (https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...) but apart from reliability assertions it's an interesting observation that they can be treated similarly if message passing mechanics are abstracted. eg they both fit asynchronous, event driven paradigms. both need elimination of shared state to not make errors in your code (required over the network).
Multicore concurrency in code isn't too hard but threads/locking are probably the wrong abstraction. Similarly, functional approaches might be a better "default" approach for a concurrent world.
Akka is sold as a concurrency abstraction that works great ay any level: one core, multicore, multi-host.
After using it for years, I can say it does work, but only with a high complexity overhead. Failure conditions, retry logic, serialization and delivery guarantrees are a concern of multi-host parallelism, but not really multicore (same process) parallelism.
I'm not sure I've ever seen an abstraction over memory-separated concurrency that doesn't add a lot of complexity. It may be that such a difference is fundamental and isn't meant to be abstracted over.
In any case, unless you are sure that you want to design for distributed parallelism, I recommend conventional thread pools, etc.
Erlang/OTP is based on the idea of location transparency to the core, I would recommend you have a look at it.
If the Erlang syntax is too weird, Elixir allows you to use ruby-like syntax on the Erlang VM. It also comes with an absolutely amazingly powerful lisp-like macro system.
Functional approaches are definitely better regarding concurrency, and distribution... if you can ship the state and the operation/function where there is availability, it can run anywhere. More complex OO relationships aren't as portable. Of course MQ systems have their own cost, on-system or across systems.
That said, the fastest computers over the past 5 years or so aren't much faster, but the power usage is much less... For example, the i5-6200u is an absolute beast of a machine for its' power consumption. This is great for server-side computing, where virtualization and other isolation strategies for allowing shared resources work well.
I don't know that we really need too much more in terms of "faster" ... the problems to be solved at this point are absolutely in systems solutions that are distributed and those communication channels. Google can deliver results of a query amazingly fast... We're going to reach a point where communication networks reach nearly every inch of livable space, and all information is (virtually) within arms length.
(divergent rambling ahead)
There are bigger issues at hand... that being physical transportation... we (in the U.S. and many other places) have more pavement for cars that we do housing space. There are optimizations to be had in the physical world that are far more pressing than if computing can get another 4-5 cycles out of moore's law. The costs of food, medication are growing kind of insane the past few years. We're pushing for younger education to the point that little kids are washing out and doing worse, instead of being little kids. On the flip side, they're so isolated that they can't handle genuine pressure/stress later in life. It's a messed up world.
Maybe we'll finally get some interesting processor architectures. The race for ever more speed has its reasons, but it's not been built on a particularly helpful abstraction layer.
Agner is legendary, but this piece is too Intel-focused. It operates under the assumption that only Intel can push the industry forward. Yes, we're unlikely to see a lot of further process reductions with Silicon, and yes power is a problem; but this is a large market with many powerful players, and assuming that it will stall because Intel stalls is extremely short-sighted.
The reality, at the moment, is that Intel may well be the only company that can push the industry forward.
Each time you introduce a new processor node, the cost of the fab goes up dramatically, and now we're talking about $14 billion for the next Samsung fab. (This is Rock's Law.)
If you go back a few years, there were a couple of dozen chip manufacturers around the leading edge, including Toshiba, Siemens, Sony, Fujitsu, NEC and Philips.
With each new step, one or two of these companies can't find or justify the money to build a very expensive fab for the next process, so they drop out.
Today, we're down to four or five: Intel, TSMC, Global Foundries (ex AMD+IBM), Samsung and maybe Europe's STM. So Toshiba, Siemens, Sony, Fujitsu, NEC, Philips and several others have all dropped out.
Which of the four or five leading companies have got both the money and the need to keep pushing on?
Looks to me like Intel and Samsung.
The only other option I can see is Apple putting a ton of money into TSMC, which current makes most of its money fabricating chips for mid-market companies like Mediatek. That's a possibility because it would stop Apple from being too reliant on Samsung.
But Intel is far from being the richest tech company out there. What's $14bln for Apple with $100s of billions of cash in the bank? It's not that much for Google either, and and other tech giants.
Which is why I suggested that Apple might put money into TSMC....
On the other hand, having pots of money doesn't actually mean a company can do anything significant in a particular area. Look at all the knock-offs in the Google Graveyard for examples.
Yes, it actually does mean 10nm wide, though it can often refer to the minimum feature size (as in not every part of the chip is 10nm wide, just some of them).
Since there's more than just silicon to a chip, those features can often be of metallic atoms, which can be smaller than Si, and hence more than 20 atoms wide.
The answer to the second unasked question is, if cost were no barrier, then the lower bound for our current class of tech is almost certainly an effective feature size of ~1.5nm, or about 5 or 6 generations. When I'm feeling bullish (usually after talking to my boys at Intel) I feel confident we'll eventually see 3nm. I suspect something more exotic will intercept by then, and carry after that in effective feature size reduction. Of course, by then, my hot-air-lifting-body-balloon unicorn will have realized, so I won't care =)
If you mean innovation in software, yes, that's probably the time for that.
If you mean innovation in specialized hardware, it's just too early. Those last iterations of fab improvement threw the prices over the roof, everything is expensive now. If Moore's law is really over, things will get cheap as they get stale, but not now.
If you mean innovation on fabrication, well, there's still some fat to cut on power consumption, and if one comes out with an absolutely flawless process, higher frequencies are still possible. But overall, one can not innovate against the laws of Nature.
That sounds like Moore law is not propelled by innovation. It's not the expanding universe which causes our transistor counts to double, it's engineers innovating.
You already see innovation from Intel to segment the market so that they can maximize profit without increasing processing speed (for example the way they artificially separate their server from their desktop CPUs). In the long run I hope you're right (and AMD is able to catch up)
Let's hope AMD and various ARM CPU vendors catch up. Intel Xenon are overpriced i7 with enabled ECC memory. And we are stuck with ~3GHz single core raw speed since 2004 (memory got faster, etc - we know!). We would benefit from 10GHz single core performance.
We're very far from hitting any theoretical limits. We're just hitting speed limits for silicon. Meanwhile, we already know several substrates that outperform silicon by orders of magnitude. Here are a few off top of my head:
There's no theoretical breakthrough needed to use these technologies, it's simply a matter of moving them from the lab to mass production. So far there has been little incentive as companies are still squeezing out the last bits of juice from silicon, but as we start hitting the limits it's only a matter of time until these technologies get phased in.
Given that Moore's law is about transistor densities, no I don't think quantum computers would qualify. It also seems premature to talk about about a Moore's law equivalent for the cost/density of quantum gates given we can barely build more than a handful at a time (D-Wave 'quantum' computers aren't quantum gate computers and don't scale in the same way).
The big one is heat. As densities go up, so do power consumption and heat dissipation for active cells. Inactive cells are OK, which is why the highest density devices are now flash memories. That doesn't help CPUs.
The next is fab cost. As someone else pointed out, state of the art fabs cost billions now, and there are fewer ones with each generation.
Finally, of course, sizes are getting close to the atomic level.
Secondary limits include electromigration (the atoms won't stay where you put them as they're pulled on by electric fields) and even X-rays not being short enough for mask etching.
Heat is the biggest problem. CPUs aren't that big; you can fit a thousand in a shoebox if you can cool them. The Bitcoin ASIC business is a worst case. Those devices need no external memory and very little I/O, but most of the gates toggle on every cycle. Mining farms are now located in cold climates near cheap power stations.