Slashdot Mirror
Princeton Researchers Announce Open Source 25-Core Processor (pcworld.com)
An anonymous reader writes: Researchers at Princeton announced at Hot Chips this week their 25-core Piton Processor. The processor was designed specifically to increase data center efficiency with novel architecture features enabling over 8,000 of these processors to be connected together to build a system with over 200,000 cores. Fabricated on IBM's 32nm process and with over 460 million transistors, Piton is one of the largest and most complex academic processors every built. The Princeton team has opened their design up and released all of the chip source code, tests, and infrastructure as open source in the OpenPiton project, enabling others to build scalable, manycore processors with potentially thousands of cores.
just shit his pants!
" Piton is one of the largest and most complex academic processors every built"
Does it mean any sanctioned country can order their own processors from a generic manufacturer?
Wish more universities would sponsor projects like this. Congratulations Princeton!
I've been hearing about massive number of cores for years ... the problem however is they are great for demonstrating that you can put a bunch of 'cores' on a chip ... not that they are actually useful for anything.
Connecting 8k of these things together? You've just proven you actually don't understand how the real world does things.
If you have 8 million cores that can add 20 super floating point numbers a second ... thats WORTHLESS because I need to do things other than add two numbers.
If you have 8k cores that can be interconnected ... that must be one awesome bus if those interconnects are useful because the congestion on that bus is going to be insane, oh ... you've got a solution to that problem? funny how that solution kills the theoretical performance
Sorry, but I've heard this stuff so many times over the years that I just get annoyed when some professor tells us about this super awesome CPU he has that is utterly fucking worthless outside of theoretical land.
And by the way, 25 cores is on the tiny side for these silly academic projects.
Blah blah blah I made this awesome processor but it only works for one tiny problem domain that can't even be used for that problem domain because of the constraints on it that allow you to make so many cores.
Not once has one of these things actually been useful in the real world, and I know thats not the point of research but the only reason you list something about so many cores is pure clickbait. No one with a clue believes you've built something useful when you make such ridiculous statements.
No, I didn't read the article. I don't have to. These papers are only about getting grant money by making ridiculous statements, not about producing anything useful and 9 times out of 8, its done using methods that the real world (read people who actually get shit done) has already deemed don't actually work outside of academia and theory.
Yes, I'm bitter. I hate useless people wasting money that could be spent doing real things, not reiterating something intel and amd knew in the 80s.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
while being able to leverage that many compute units all a once is quite impressive, most tasks are still serial by nature. computers are not clairvoyant, so cannor know in advance what a branched logic chain will tell them to do for any arbitrary path depth, nor can they perform a computation on data that doesnt exist yet.
thhe benefits of more cores are from parallel execution, not from doing tasks faster. as such, most software is not going to benefit from having access to 8000 more threads.
With a multiuser, multitasking OS you can have 25 different unrelated processes running on something with 25 cores. Or you could have 25 threads in a dataflow arrangement where each is a consumer of what the last just produced. Or you could go over the members of an array or matrix 25 members at a time with the same transformation. Some things are serial, but there are plenty of ways more cores can actually be used.
Unless the computer is figuring out every possible combination 1, 2, or more steps ahead. That how computers beat chess and could really improve in predictive modeling. Depth/Lookahead depends on how fast the logic flow branches. To think about it more, it'd be a great factor in human predictive analysis, from driving to combat.
lelelelelelelelelelelelel....GO TEAM GREEN!!!!!!!!11111111oneoneoneoneone
the type of cores:
Some of OpenPiton® features are listed below:
OpenSPARC T1 Cores (SPARC V9)
Written in Verilog HDL
Scalable up to 1/2 Billion Cores
Large Test Suite (>8000 tests)
Single Tile FPGA (Xilinx ML605) Prototype
The bit that may put some people off:
This work was partially supported by the NSF under Grants No. CCF-1217553, CCF-1453112, and CCF-1438980, AFOSR under Grant No. FA9550-14-1-0148, and DARPA under Grants No. N66001-14-1-4040 and HR0011-13-2-0005. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of our sponsors.
So interesting and possibly FGPA synthesizable test processor it may be. Trustworthy computer core it may *NOT* be. (You would have to compare it to the original T1 cores, and have had those independently audited to ensure no nefarious timing attacks, etc were in place.)
Now, having said that, if this interconnect is even a fraction as good as they claim, it could make for an AWESOME libre SPARC implementation competitive with Intel/AMD for non-Wintel computing uses. Bonus for someone taping out an AM3+ socket chip (or AM4 if all the signed firmware is SoC-side and not motherboard/southbridge side.) that can be initialized on a commercially available board with standard expansion hardware. AM3/3+ would offer both IGP and discrete graphics options if a chip could be spun out by middle of 2017, and if AMD was convinced to continue manufacturing their AM3 chipset lines we could have 'libreboot/os' systems for everything except certain hardwares initialization blobs. IOMMUv1 support on the 9x0(!960) chipsets could handle most of the untrustworthy hardware in a sandbox as well, although you would lose out on HSA/XeonPhi support due to the lack of 64 bit BARs and memory ranges.
Instead of branch prediction picking the most often used branch, and stalling when they get it wrong, just take all possible branches and toss out the ones that turned out to be wrong.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
Or you can fake it with really good scheduling and context switching. Why is it that I was able to simultaneously watch a realplayer video in Netscape 4.x while editing a doc in OpenOffice with NO lag or skips or jitters, on a 200mHz box with 1 gig of ram in 1998, but I can't do that now with 2.6 gHz and 4 gigs? This is starting to really bug me, like where the FUCV is all that horsepower going???
NOTE all of this is on Linux, various flavors. My Time-Warner cable is easily able to saturate the box during off-peak hours.
C|N>K
In practice, most jobs running on a computer have some relation to each other, and the more jobs you have - and this CPU clearly expects to be able to run a lot of jobs - the more likely that will be. (Where I work, we actually have an application that gets slower when you add more cores.) Like most CPUs with high core counts, this one looks like it'll be great at compute-intensive tasks, but as soon as you try to do I/O, it'll slow to a crawl. Given the number of terabytes people are trying to process these days, I'm thinking this CPU's applications are limited
Sit, Ubuntu, sit. Good dog.
Now that was a good /. post, reminiscent of yesteryear.
Get off my lawn.
With a multiuser, multitasking OS you can have 25 different unrelated processes running on something with 25 cores. Or you could have 25 threads in a dataflow arrangement where each is a consumer of what the last just produced. Or you could go over the members of an array or matrix 25 members at a time with the same transformation. Some things are serial, but there are plenty of ways more cores can actually be used.
Nope. You'll generally hit the wall with around 16-20 cores using shared memory. You need distinct processors with dedicated memory to make multi-processing scale beyond 20 or so processors. Those huge servers with 32-cores apiece have their point of dminishing returns/processor after around 20 cores.
First, the reason you aren't going to be doing multithreading/shared-memory on any known computer architectures, read this.
Secondly, let's say you aren't multithreading so you don't run into the problems in the link I posted above. Let's assume you run 25 separate tasks. You still run into the same problem, but at a lower level. The shared-memory is the throttle, because the memory only has a single bus. So you have 1000 cores. Each time an instruction has to be fetched[1] for one of those processors it needs exclusive access to those address lines that go to the memory. The odds of a core getting access to memory is roughly 1/n (n=number of cores/processors).
On a 8-core machine, a processor will be placed into a wait queue roughly 7 out of 8 times that it needs access. Further, The expected length of time in the queue is (1-(1/8)). This is of course, for an 8-core system. Adding more cores results in the waiting time increasing asymptotically towards infinity.
So, no. More cores sharing the same memory is not the answer. More cores with private memory is the answer but we don't have any operating system that can actually take advantage of that.
A project that I am eyeing for next year is putting together a system that can effectively spread out the operating system over multiple physical memorys. While I do not think that this is feasible, it's actually not a bad hobby to tinker with :-)
[1] Even though they'd be fetched in blocks, they still need to be fetched; a single incorrect speculative path will invalidate the entire cache.
I'm a minority race. Save your vitriol for white people.
Chances are you're not content to watch video in 240p anymore.
So, can I see your 16nm Fab?
Perhaps more interesting is the semi-detailed presentation about AMD's Zen. Other people have already pointed out that a paltry few hundred million transistors doesn't get you very far. What are the billions of transistors used for? The Zen presentation is quite informative. Loads of cache is a fair chunk of it. Überfancy predictive logic is another big chunk of it. The rest is absorbed by 4 completely parallel ALUs, two parallel AGUs, and a completely independent floating point section with two MUL and two ADD logics. And after all that, what you get is parity with Intel's Broadwell. Barely.
So for perspective, that took a decade of hard labor by quite well paid engineers, and there was no low-hanging fruit in the form of the register-starved x86 architecture for AMD to pluck this time. The difference between half a billion and two billion transistors is very very substantial.
But the whole point of parallel execution is to reduce serial cycle times which means it is going to be faster overall. The clock speed race was ended years ago, we are multi-threading everything now, and understanding chips like these will help in our understanding of future computing.
Predictive branching on 32 cores is useless. On 200,000 cores, it is trivial. Don't be so willfully dull.
Tinfoil is apt in many circumstances, but geez keep it where it belongs.
Silence is a state of mime.
SLOWER with more cores? Sounds like your application was written by a bunch of fools. Worst case is that those cores should go unused.
On a 8-core machine, a processor will be placed into a wait queue roughly 7 out of 8 times that it needs access. Further, The expected length of time in the queue is (1-(1/8)). This is of course, for an 8-core system. Adding more cores results in the waiting time increasing asymptotically towards infinity.
Sorry, that doesn't sound right. The expected length of time in the queue should be on the order of nt, where n is the number of cores and t is the average time required to process a memory-request. (A better formula would use the average length of the queue instead of n but to first order it still would be roughly linear with n.) So, the time required would increase linearly with the number of cores.
If it weren't for deadlines, nothing would be late.
There is a class of problems that are, amusingly enough, called "embarrassingly parallel." Those tasks are perfect for this kind of thing. Think of things like ray-tracing or key-cutting (hello NSA!) where there are no dependencies between operations. Split those amongst 8k CPUs and you can get some serious speed out of a embarrassingly large number of cores.
https://en.m.wikipedia.org/wiki/Embarrassingly_parallel
Just as there is the super-linear scaling effect (very uncommon) there's also the effect that a multiprocessor system, even if not loaded, can produce worse performance than the ideal _even_ when written competently. Systems have to use different algorithms for different kinds of system to get good scaling, if the system isn't loaded with the workload the system is designed for those algorithms are unlikely to be optimal and performance then scales worse than expected. That includes hardware algorithms like data/instruction prefetch, cache coherency, DRAM management etc.
But you talk like someone that have no freaking clue of real world systems. Do you think synchronization and coherence (hardware _and_ software for distributed systems) are cheap operations? Nope. When the overheads of added cores exceed the extra performance they can provide the system will run slower with more cores, it is that simple. Most interesting synchronization algorithms scale as O(n^2) or O(n*log n), do the math.
I think he meant the AFOSR and DARPA involvement.
I imagine the poster was referring to DARPA more than the NSF, but I imagine that any association with the US Govt. could engender distrust in such matters these (post Snowden) days.
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
That's called eager execution (well, it have many names but that's the most common).
In general it is a dumb idea. It requires more instruction throughput, more execution units, larger caches etc. for a small gain which in the real world is probably negative. Doing more things means more switching, switching means more power consumption (and the added resources will add to the leakage current too -> more power) and this means lower effective clock frequency.
Even the limited form of eager execution where only branches that are considered unpredictable have both their paths executed there isn't much gain and the overheads most likely not worth it.
It's an interesting idea, and one I have given a little thought to. ( it would enable a very fault tolerant computer architecture) however, unless you implement highly redundant interconnects/busses, you still have the N-devices fighting for a shared resource problem.
If you make the assertion that all nodes have a private direct connection with all other nodes, and thus eliminate the bottleneck that way, you now have to gracefully decide how to handle a downed private link.
I suppose a hybrid might work. Fully dedicated links, and one shared bus. When dedicated link fails, communicate over the shared bus.
Scaling such a design would become prohibitively costly though. A 200 node design would have orders of magnitude more dedicated links.
The idea I had for playing with this idea, was to use some cheap wired home routers, set up private vlans on the 5 or so ethernet ports each has, then put private patch cables on each port, then put all the Wan ports on a dumb hub.
The local copies of Linux on each system can handle management of local device resources, and a daemon running on each node then handles listening/responding on each interface.
Just what such a thing would be good at doing escapes me though. To be really useful, you would need some way to have nodes specialize, then cooperate, without a central authority.
That way, should we decide to use this network to process live video, one node decodes the input stream, then dispatches portions of the decoded stream to peer devices, who then take the decoded stream and do whatever processing is requested, before sending the processed streams to yet another peer device which assembles the processed stream, then shuttles that to the endpoint node, which reencodes the stream and writes it to the output device. (Or some similarly cellular process)
I suppose this is kinda similar to how a neural colum works, where locally interconnected nets are restricted in the number of true local peers they have, and then communicate collectively to other neUral columns by dedicated interconnects. (Video input source in the above, could be from a camera, but it could also be from another network's output stream.)
The major logical tasks are:
Role selection in the assigned task for each local node.
How to issue instructions to the mesh nodes in a decentralized manner
Depending on how far you wanted to extrapolate this, each mesh node could be treated as a logical unit, where each logical node then is part of another, higher level node of similar topology: each mesh has a direct connection to each other mesh inside its higher order node, and one communal link all nodes can talk on inside that node.
Eg, if I make 5, 5node networks made out of such routers, I need 7 ports on each router. 5 for direct local traffic. 1 for local shared connect, 1 for direct connect to another 5node group. Clever use of subnetting and routing on the shared net would enable there to be a dumb gateway device to allow the shared higher link to function. Each 5node network is connected to every other 5-node network in the scaled up version.
Decisions on how to process incoming data might be tied to which interface received it, or any number of other methods.
Spying on the system state of the whole system should be possible through the shared link infrastructure, though ideally any node you interact with the system with should be a proper peer in it, and nit something sitting on the shared net only.
The drawback of such a design will be signal propogation latency, and keepin all the subnodes, at all levels, synchronized. The human brain uses a support network of astrocytes and glial cells to guide dedicated link physical routing, and to tune propogation delay between neural columns through selective mylienation of trunk bundles.
You could probably fake it with introduced waitstates.
At some point though, the behavior of the whole will revolve around the basic logic baked inside each physical compute unit. Ideall
I asked her to open her legs because I found them embarrassingly parallel. She told me I didn't have the appropriate permissions. So I just crashed there. Later, after I was re-booted, I left.
That isn't possible. First the number of possibilities explode fast and second we are already at a power wall. Modern processors already do speculative computation however only in cases where it is likely the result is correct and needed. Just adding speculative execution will make the computer slower partially due to extra data movements (caches etc.) and partially because it will consume more power on a chip already difficult to cool.
Branch predictors are doing most of the work already and doing it well.
Also, there is caching, and also, some loads are heavy on longish FPU operations.
So... it doesn't quite work out that way. Also, multicore designs can have separate memory.
One example of multicore design that's both interesting and functional are the various vector processor graphics cores. Lots of em in there; and they get to do a lot of useful work you couldn't really do any other way with similar clock speeds and process tech.
I've fallen off your lawn, and I can't get up.
Parallel execution doesn't reduce serial sections - look at Amdahl's law.
Having large parallel systems is a well researched area and I can't see anything this system will do to help improve the state of art. Well the state of art of building processors with huge amounts of processors perhaps.
Or less. Remember, he said 1998.
With that complexity, how can you ever be sure it doesn't contain backdoors. You cannot trust DARPA.
That sounds like we're starting to re-invent the Itanium.
-- "This world is a comedy to those who think, a tragedy to those who feel."
In the multi user, multi tasking scenario, I guarantee those processes will never all be CPU bound unless one asshole is trying to make a point.
They'll be stalling for cache misses most of the time they even spend on the CPUs and then waiting on IO.
well, nothing will ever break amdahl's law. But that is rarely the issue. The parallelism is many scientific problem is pretty vast. We run lots of simulations on 100K and more cores. Often the interconnect is the issue, and not the sequential part.
There is a real problem today in build a exaflops machine, one of the biggest problem is managing communications because they are very power consuming. If that architecture can scale meaningful codes at 100K, it is interesting.
That is not really true. Most workloads can be executed in parallel. Pretty much all the field of scientific computing (would that be physics, chemistry, or biology) are typically quite parallel. If you are looking at database and data analytics, they are very parallel as well, if you are building topic models of the web, or trying to find correlation in twitter post, these things are highly parallel.
Even on your machine, you are certainly using a fair amount of parallel computing, most likely video decompression is done in parallel (or it should be). It is the old argument that by decreasing frequency you can increase core count in the same power envelop while increasing performance.
For sure, some applications are not sequential. Most likely, they are not the one we really care about. Otherwise, hire me, and I'll write them in parallel :)
The good news is that this thing uses an existing processor core, OpenSPARC T1 (SPARC V9), so there's plenty of software around for it. (Yes, it runs -- or I imagine it will soon -- Linux.)
The bad news is that this thing uses an existing processor core, instead of a more secure architecture (say, something segment based with tag bits, like the B6700 among others) which would render it much more resistant (dare I say immune?) to things like buffer overflows and such.
-- Alastair
If there is not working systems - how does that help anyone
OpenOffice didn't exist in 1998.
Now you get tenure
On a 8-core machine, a processor will be placed into a wait queue roughly 7 out of 8 times that it needs access. Further, The expected length of time in the queue is (1-(1/8)). This is of course, for an 8-core system. Adding more cores results in the waiting time increasing asymptotically towards infinity.
Sorry, that doesn't sound right. The expected length of time in the queue should be on the order of nt, where n is the number of cores and t is the average time required to process a memory-request. (A better formula would use the average length of the queue instead of n but to first order it still would be roughly linear with n.) So, the time required would increase linearly with the number of cores.
You're right, I worded it incorrectly (it's late, and I've been working 80hrs/week for the last year due to a private project. Forgive me). What I meant to say was "The expected delay when accessing memory is (1-(1/n))", but even that is off by an entire exponent.
The expected delay is (probability of queueing) X ( probable length queue). The probability of queuing is (1-(1/n)):
With 2 processors, you have a 1/2 chance of getting exclusive access, (1-(1/2)) of queuing.
With 3 processors, you have a 1/3 chance of getting exclusive access, (1-(1/3)) of queuing.
With 4 processors, you have a 1/4 chance of getting exclusive access, (1-(1/4)) of queuing.
With n processors, you have a 1/n chance of getting exclusive access, (1-(1/n)) of queuing.
The probable length of the queue is linearly proportional to n, so the expected delay is (1-(1/n) * n). In terms of performance this is O(n^2) - IOW it's piss-poor performance.
Or maybe I'm still doing the numbers wrong - feel free to derive a better statistic for predicting time-in-queue when processors are all using a single address bus. This is the one I got, and some trivial simulation does actually fit this profile.
I'm a minority race. Save your vitriol for white people.
For those wondering why the distrust, here is a good article describing why the US govt is not to be trusted.
Nope. You'll generally hit the wall with around 16-20 cores using shared memory. You need distinct processors with dedicated memory to make multi-processing scale beyond 20 or so processors. Those huge servers with 32-cores apiece have their point of dminishing returns/processor after around 20 cores.
Doesn't NUMA handle this at least if your usage pattern allows the data to mostly stick near the associated processor? I suppose if you have that many cores in one processor it may be an issue...
They're not the government, they're funded by government grants. As someone who has been funded by government grants, I can assure you it is completely different.
SJW n. One who posts facts.
OpenOffice didn't exist in 1998.
Neither did the troll/charity shill you're responding to.
Sure it is, buddy.
Sure it.
Your GPU would disagree.
The real question is: are there instances where a SPARC instruction set would be a better fit than the simple GPU concept of 'cores'.
That is why you design multithreaded programs to avoid bottlenecks. A fair number of applications scale just fine to many hundreds of CPUs.
But yes, if you just aimlessly hack a single-threaded design to use random synchronization primitives, you will lose. And you will deserve to lose.
https://kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html
So, no. More cores sharing the same memory is not the answer. More cores with private memory is the answer but we don't have any operating system that can actually take advantage of that. A project that I am eyeing for next year is putting together a system that can effectively spread out the operating system over multiple physical memorys. While I do not think that this is feasible, it's actually not a bad hobby to tinker with :-)
I thought Plan 9 was actually doing this?
Ezekiel 23:20
That is why you design multithreaded programs to avoid bottlenecks. A fair number of applications scale just fine to many hundreds of CPUs.
But yes, if you just aimlessly hack a single-threaded design to use random synchronization primitives, you will lose.
Did you even read anything I wrote? Please tell me - exactly what multi-thread design do you know off that can solve the contention for the 48-53 pieces of copper that goes to the RAM? There's only one memory bus, and every instruction that must be executed travels on it before execution.
I'm a minority race. Save your vitriol for white people.
Actually, why are they going w/ IBM, who I thought had exited the semiconductor market? Why not go w/ the best of them - Intel? Speaking of which, I wonder - which CPU's ISP do they use?
I would first start by making the main memory bus as wide as the L3/L4 cache line, and make *that* one as large as possible. But ultimately, all sharing works only to some extent, so thinking distributed wins big. There's still coherence in program executions. The mere ability to access a unit of data in a shared address space that is currently far away shouldn't mean that you'd be doing this at a high rate.
Ezekiel 23:20
Speculative execution? That's already happening, isn't it?
Ezekiel 23:20
That's what a number of RISC processors used to do - execute both branches of an instruction, and flushing out the one that turned out wrong.
Uh, no, in the original Itanium, it was the compiler that was supposed to do the branch prediction
Ok, so it's OpenSPARC based? That's cool. So what do they have running on it - Linux, BSD or Solaris?
It was called StarOffice back in those days.
Branch delay slots? Register windows? This is one of the first RISC architectures, and it has warts. Fujitsu just abandoned it.
A project that I am eyeing for next year is putting together a system that can effectively spread out the operating system over multiple physical memorys. While I do not think that this is feasible, it's actually not a bad hobby to tinker with :-)
SGI did that since the late 90s, calling it ccNUMA (cache coherent non-uniform memory access). NUMA is common on the many-core CoreI and AMD systems, where each groups of cores have "their own" memory bus.
Suppose you treat these identical processor cores like LUTs in an FPGA and perhaps group clusters of these cores together in hardware into some sort of logical device an OS can utilize. Each device has programmable interconnect between the cores - that's going to be a lot of switching fabric. Part of the software compilation process or even software installation process includes an analysis and synthesis stage to create the best interconnect for the application. The OS runs the software by programming the interconnect then loading the object code. This would all help with the versatility issue but may still be too expensive.
This is an interesting problem domain that's going to get more and more attention since it's easier to lay down more cores than to make those cores run at higher clock frequencies.
You just snuck into your analysis the assumption that every core is memory saturated, and I don't think that all the memory path aggregates in many designs until the L3 cache (usually L1 not shared, L2 perhaps shared a bit). The real bottleneck ends up being the cache coherency protocol, and cache snoop events, handled on a separate bus, which might even have concurrent request channels.
I think in Intel's Xeon E5 line-up there are single-ring and bridged double-ring SKUs for forwarding dirty cache lines from one cache to another (and perhaps all memory requests). This resource can also drown for many workloads.
In many systems, you have all these cores running tasks which are fairly well isolated (not much cache conflict), except they all want to be able to allocate as much memory as they need from a giant memory space (e.g. a TB of DRAM) so they fundamentally have to fall through to a shared memory allocation framework.
You can learn a lot about the challenges involved by following the winding path of something like jemalloc as increasing concurrency levels expose yet another degeneracy.
The real problem with this field is that there isn't a single, simple story like the one you tried to tell. There are usually dozens of ways to skin the cat, each with completely different scaling stories, with different sets of engineers who are good as tweaking or debugging those stories.
At this point, what you have is a fragile coordination problem between your solution space, your architecture, and the engineers you employ, forcing ambitious ventures to crack out the golden recipe: pour in seven cement mixers full of head hunters, one 55-gallon oil drum of exclamation marks, a metric butter tonne of job perks, and agitate appropriately.
24min anime fit in 40MiB of space back then.
I've managed super-linear a few times with multi-threading. Required good use of cache. If you can get the threads to be pseudo-synchronized without having to use any actually synchronization, what the first thread reads from memory, the other threads can benefit from. This case only applies to cores that share the same cache. The "super-linear" part no longer applied adding more sockets/CPUs, and adding more cores had diminishing returns, approaching a fixed percentage increase in performance over a single thread.
Then I tell people I code in C# and they don't understand how someone who writes in a high level language know how to think so low level. Lets just say I'm that go-to guy when you can't empirically find why your code is slow. Many hard performance issues cannot be measured because measuring can change the outcome. At that point you need a good mental model of how CPUs, cache, memory, OSes, threads schedulers, io schedulers, harddrives, SSDs, and networks interact to produce strange slowness when no one part is the bottleneck. Almost always an issue of latency vs throughput and different parts of the system with different throughput or latency characteristics.
Also, multicore designs can have separate memory.
NUMA comes to mind but it has complexity issues added to the OS and application. Accessing another CPU's memory is expensive, so the OS needs to try to keep the threads close to the data. The applications need to try to do cross socket communication by using a system API, assuming it exists, to find out which socket the thread is on and trying best to limit to current socket threads. Cross socket communication is probably best done via passing messages instead of reference because copying and storing the data locally, even if duplicated, will be faster than constantly accessing the other socket's memory.
Then you have the issue of load balancing memory allocations. May not always be an issue but it can become an issue if you consume all of one socket's memory. There are other issues like one socket may have direct access to the NIC while the other socket has direct access to the harddrives. Topology is important.
As soon as you step out of a cache-coherent system, then you run into even more fun problems. Stale data is a huge issue. You need to make sure you're always getting the current data and not some local copy. At the same time, without cache-coherency, cross core communication is very high latency. Most x86 CPUs can remain cache-coherent into single cycle latencies. While copying the data may not be any faster, you know if the data changed very very quickly. If the data is read a lot and rarely changed, then you have some nice guarantees about how quickly you know if the data changed and only incur the access cost when that event happens. Without coherency , you are now forced to check out to memory every time, incurring high latency costs every access.
With multi-core systems, cache-coherency has an N^2 problem. I'm sure someone will come up with an idea of "channels" to facilitate low latency inter-core communication while allowing normal memory access to be separate. Possibly even islands of cache-coherency in an ocean of cores. Each island can be a small group. Some of the many-core designs where they have 80+ cores have heavy locality issues. Adjacent cores are fast to access and far aware cores are very expensive. Pretty much think of each core only able to talk to adjacent cores, and requests to far away cores need to go many "hops". Even worse is cores physically nearer the memory controller have faster access to the memory. All memory requests have to go through these cores. Lots of fun issues that requires custom OS designs.
That's why the many core server CPUs have massive L3 caches and quad channel memory. 24 core x86 CPU with around 60MiB of L3 cache? Why not? More memory channels allow more concurrency of access. Intel NICs support written packets directly to L3 cache as to skip memory writes. Large on NIC buffers to make better use of DMA collecting and reduce memory operations, transferring in larger chunks to make use of that high bandwidth memory.
In case it's not clear, I'm not trying to say your point isn't valid, just saying your point explains a lot of current features in high end components.
Are most tasks serial? Brains have a really low clock rate, and a ludicrous number of parrallel execution units. Humans definitely win the "variety of tasks" award over computers, though.
Multicore is fine. The software just sucks still.
It might engender quantitatively more distrust than in pre-Snowden days, but probably not deeper distrust. The US government has been deeply distrusted by the rest of the world for a long time.
Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"