Slashdot Mirror
Ask Slashdot: Why Are There No Huge Leaps Forward In CPU/GPU Power?
dryriver writes: We all know that CPUs and GPUs and other electronic chips get a little faster with each generation produced. But one thing never seems to happen -- a CPU/GPU manufacturer suddenly announcing a next generation chip that is, say, 4-8 times faster than the fastest model they had 2 years ago. There are moderate leaps forward all the time, but seemingly never a HUGE leap forward due to, say, someone clever in R&D discovering a much faster way to process computing instructions. Is this because huge leaps forward in computing power are technically or physically impossible/improbable? Or is nobody in R&D looking for that huge leap forward, and rather focused on delivering a moderate leap forward every 2 years? Maybe striving for that "rare huge leap forward in computing power" is simply too expensive for chip manufacturers? Precisely what is the reason that there is never a next-gen CPU or GPU that is, say, advertised as being 16 times faster than the one that came 2 years before it due to some major breakthrough in chip engineering and manufacturing?
Physics
-- Sometimes you have to turn the lights off in order to see.
Most likely, there is no major competition in the market, and PC sales on the whole have slowed considerably. A modern 6800K processor is as close as you'll come to a leap forward, but it's $1100 Canadian and requires a similarly expensive motherboard + memory. Same with similar chips.
Meanwhile the cheapest system on the market is as fast as a moderately high-grade enthusiast computer from 2010 and probably has reasonable 3D graphics onboard, with a SSD drive it will feel quite snappy.
So, a) not a lot of market demand for faster systems, b) lots of tablets and game consoles for entertainment out there, c) moderately faster systems exist but cost keeps them low-volume, d) very low-percentage demand for faster computers - definitely less than 1% that will pay a premium for it, e) the majority of gamers are young-ish and they play largely twitch games even on PCs which are more GPU limited than CPU limited.
...Steve
Every advance has to be paid for by the consumer. Each incremental advance comes as the previous one is marketed.
Instruction level parallelism in superscaler core designs have hit a limit. More pipeline stages becomes counter productive when a misprediction requires a flush. Thread level parallelism exploited by multi core designs can only go so far; only certain tasks can exploit massive parallelism(e.g. ray tracing).
Increases in clock speed have hit a wall with current silicon based semiconductors. Exotic semiconductors and incredible cooling systems aren't practical for the mass market.
NVIDIA's 2016 Pascal architecture was significantly faster than their previous Maxwell architecture.
"Relative to GTX 980 then, we're looking at an average performance gain of 66% at 1440p, and 71% at 4K. This is a very significant step up for GTX 980 owners,"
http://www.anandtech.com/show/10325/the-nvidia-geforce-gtx-1080-and-1070-founders-edition-review/32
The poster asks a question that assumes breakthroughs can be planned just like any other development project. But breakthroughs are not, or rather, those that can be planned and worked already have been. The computer science field has been operating awash with funding for at least 55 years.
I'm not saying there are no breathoughts out there, what I'm saying is that our current project methodology has already discovered all it can, and most future breathoughs will come from some other methodology.
The target, CPU/GPU power is also not especially compelling -- compared to the past, there is much less pressure to increase performance, and considerable uncertainty how the increase will be helpful.
The sole reason Kaby lakes got hot and clocked in so fast is because of AMD just around the corner and it worked to beat Ryzen. I expect the CPU race to heat back up again as physics has not killed innovation yet.
Proof is GPU's and Phones are still improving at breakneck speed. It is only because of an INtel monopoly that on the desktop it has went to a standstill.
http://saveie6.com/
Right about 2008/2009 computer hardware became "good enough" to appeal to people's basic needs which really only centered on having a simple window to the internet. Netbooks became available and smartphones started to become good enough to browse the internet on their own. Consumers at the end of the day really only want a platform that's able to view into the internet.
Someone can correct me, but I believe such innovation is still occurring for server technology and niche fields like a/v production, cad, and animation. Though, I do yearn for the olden days when consumer technology was cool and exciting. Being a tech nerd in the 90s was something else!
...because of software inefficiency and planned obsolescence. Ever wonder why current Windoze takes about the same time to boot as Win 3.1 running on a 486? It's not because Windoze does 10,000 times more (useful stuff) today. (486DX2 ~25 MIPS, i7 5960X ~240K MIPS).
"National Security is the chief cause of national insecurity." - Celine's First Law
I remember when Pentiums were first coming out. P75, P90, P100, P133, P166. They were faster than the 386s and 486sx and 486dx models. The p166 was noticeably more than twice as fast as the P75 on lots of tests. The Mhz and Ghz races are over.
We can't just ramp up cycles anymore with silicon. It puts out too much heat. Multicore doesn't magically make programs faster unless they lend themselves well to parallellization & are coded properly for it. New architectures have been tried, but ultimately fail because they're costly or proprietary. ARM was a pretty good leap forward for mobile use. New instructions are being included in CPUs all the time -- especially ARM. Try to play a HEVC 1080p video on a 2013 tablet vs one today... you'll notice a difference right away. Check the CPU usage -- one's at 100% and dropping frames left and right while the other barely nudges past 15%.
Intel or AMD could sell you a chip with 256 cores on it, but unless you do a lot of video encoding or physics rendering, it'd be wasted on you... and super expensive b/c they have no incentive to make it in volume. Maybe when VR or AI becomes commonplace, you'll drive demand for such architectures.
CPUs are fast enough for just about anything one could think to do with them at a consumer level. GPUs can be made better, but market forces push for low power that's "good enough" for most users. CPUs and even GPUs aren't the bottlenecks anymore -- it's RAM, SSD, PCI-express lanes, various busses like USB, thunderbolt, HDMI, SATA, etc. Doesn't do much good to stuff a really fast CPU or GPU into a system if you can't feed it data fast enough to max it out. Most CPUs already have several layers of cache as well as branch prediction to help with the crippling latency from other I/O, but it's still not enough.
Changes are usually evolutionary, not revolutionary... and we've tweaked so much with CPUs and GPUs, you're not going to see a big bump until we move away from silicon and PCB to say... diamond or carbon nano-wires and optical computing.
CPU architect here. I'll try to provide some insight.
Performance for CPU/GPU or any computational tool isn't exactly just a number you hit. It's not like bandwidth for storage or communications nor is it like a battery's capacity.
A CPU and to a lesser extent a GPU is able to perform all sorts (all logical) computational functions. Each of these involves different usage patterns of the different computational paths inside a piece of silicon. And thus, speeding up each of these usage patterns requires different structures.
A single piece of code running something complex like launching an app or opening a webpage will generate hundreds of millions of instructions with lots of different patterns. Think about all those API's you call. How much code do you think is similar between them?
And thus the problem of improving "performance". The goalpost is a shifty one. Speed up one code pattern, and you risk your changes hurting another. Or you can spend extra transistors making a specialized accelerator for that code pattern. But then...it'll be idle 95% of the time.
And if you speed up a particular function by 1000x (it's happened), your average speed increase for a typical benchmark or API call will still be 0-1%. Because that function is only a small piece of the larger codebase.
Think about how many non-similar libraries and functions there are in typical software, and think about how there's any way to speed them *all* up. You can make memcpy or memset (malloc uses these) faster by 5x and that'll speed up javascript processing by....0.01% or so.
The reason "performance" doesn't increase as drastically in the computer world is because computing "performance" is very very multifaceted. Much like how "intelligence" can't just be increased by 5x -- someone can get 5x better at specific tasks, like memorizing or image recognition, but that doesn't make them 5x more "intelligent".
Compare this with a simple metric like 0-60 acceleration or network bandwidth.
Architecture-wise, Pascal was mostly an incremental upgrade to Maxwell.
The big difference from Maxwell to Pascal was a process upgrade from 28 nm to 16/14 nm which allowed the clock speed to bump 50% from around 1 GHz to around 1.5 GHz.
Couple that improved memory and a good balance of different types of units for the best performance in typical games of its time.
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
This question lacks context. In terms of desktop PCs and common everyday usage, we don't NEED more speed or power. Nothing is going to speed up webpages or Facebook or whatever people typically do on their PCs. And even if you did, then you become constrained by the speed of the internet and there won't be much perceived benefit.
On the mobile side, there is room for more speed but it comes at the expense of power and is still constrained by connection speeds and website performance on mobile devices, which often sucks. Throwing faster and more processing isn't necessarily the fix that is needed.
There are cases where rendering and other heavy duty uses might benefit but the vast majority of people never use those things. Even gaming is usually constrained by other things like the GPU, the game engine, connection speed, and human performance.
The major places where computing power is much more important are in things like supercomputing but those machines don't run desktop programs and don't work the same way. Only the people directly using those machines would ever have any idea how fast they are or how much faster they wish they could be.
So, to recap, desktop PCs are adequate, mobile devices are still finding a balance between power and power usage, gamers are off on their own island but sheer CPU isn't a magic fix, and supercomputing, where extra power would matter, is so far removed from everyday users, there is no way to relate to it.
Sig for hire.
Speed of electrons or even light isn't the problem. It's the capacitance. The destination transistor feels the voltage change at the speed of light, but it doesn't change its own stored charge fast enough to register a "0" or "1". This has much more to do with intrinsic resistance of the material locally than how far the signal has to travel.
The problem is that a material that's a semiconductor will typically straddle some range between conductance and resistance (by definition). So conductance is hard to increase without impacting the resistive "mode" it needs to be set in. This is the problem with graphene and carbon nanotubes. They're really conductive, but not terribly resistive when we want them to be in the "off" mode.
Moore's law had a great run: ~40 years from early 60s to early 00s.
During that time, every generation boosted density, gate count, clock speed, and value per dollar.
The (exponential!) rule of thumb was 2x more every 18 months.
Everyone knew it had stop sometime: you can't make things smaller than atoms.
What finally did stop it (considerably north of atom-scale) was gate tunnelling current.
In a MOS-FET, the gate is separated from the channel by an insulator (SiO2).
As you scale the transistor down, that insulator gets thinner, along with everything else.
When the insulator thickness is less than the wavelength of an electron, you start to get significant tunnelling current.
This acts like short-circuit from the power to ground.
The technology hit the wall around 2003.
Gate tunnelling current was then over half of total power dissipation.
The power density of the CPU chip was 150 W/cm^2 (like a stove top),
and going further was clearly impractical.
As it happens, the clock speed at that design node was 3 GHz,
and that's pretty much were we are today.
Everything since then has been building bigger, not faster: multi-core, caches, SoC;
plus architecture tweaks and optimizations, like pipelining and super-scalar.
It was a great run while it lasted, but it's over,
and we're not getting another one without a fundamental scientific/technological breakthrough,
on the order of coal, or steel, or quantum mechanics.
Moore's Law is an observation made by its namesake that the density of transistors on a chip doubles approximately once every 18 to 24 months. Gordon Moore first made the prediction in 1965 and it held fairly well until recent years (roughly after 2012.)
Processor speeds, although they have increased significantly over the same time period, have not doubled every 18 to 24 months.
If it weren't for deadlines, nothing would be late.
Risk averse CEOs who don't want to sink in the R&D to make carbon based chips because there is risk of it not working.
A synthetic diamond transistor was first built and tested over 13 years ago at 81GHz: http://www.geek.com/blurb/81gh...
More recently they developed a 300GHz Graphene transistor, but that was still 7 years ago: https://www.bit-tech.net/news/...
The technology is there and proven, but scaling it up to processor scale would be a massive investment and a big risk.
If you disagree, please post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like
Most of Pascal's increases come from dropping to a much smaller node size which allowed them to add a lot more cores in a smaller thermal envelope. That's why it bugs me that they jacked up the prices and are fusing them off to create artificial tiers - it's mostly more of the same. And they'll continue to be able to do that because there is almost no limit to the number of cores you can throw at the types of problems GPUs are used for.
My Chromebook takes mere seconds to boot, whereas an IBM AT could easily take minutes. And of course, my modern device performs tasks that would have been the domain of supercomputers in the past.
Time to take off the rose colored glasses. I did live through the eighties and nineties, and computing was pathetic back then ... we just didn't know any better
My Commodore 64 took about 0.1 seconds to boot. We just suck at "fast" these days.
Socialism: a lie told by totalitarians and believed by fools.
This kind of thing was rather common until about 2000. Each process node was better in every way than the last. Big jumps in performance at each node advance. Power went down too. And, of course it was much cheaper per gate. You could get doubled performance and 1/4 the cost by just porting over the same design, trace for trace, to the next full node. These "die shrinks" were quite common. Through the 90's you got an extra bonus for new designs. That is because the industry was brimming with ideas that were known to work but were just not practical to implement because they took too much silicon area.
First the idea spigot sputtered. The good mainframe ideas had already been implemented. It was longer clear what to do with all those gates. New ideas were tried. Some worked. Some didn't. Also, about this time, complexity started to threaten the ability to make chips that actually worked. Bugs became more common. Design progress slowed.
Then process starting acting up. Power scaling stopped. More transistors were available but if you used them, your chip consumed proportionally more power. Run the transistors faster and you had the same problem, only worse. A hot chip was no longer a marketing problem, it was a chip that would not work. More effort and more complexity were needed to tame power. A simple die shrink wouldn't do that much.
Then process started getting messier. The new nodes were not better in every way. Leakage current went up instead of down. Variability went up. Performance scaling slowed. Getting any improvement at all required more development time and money. Progress always slows when development time and cost rise.
Then 20nm planer came and it was awful. Terrible leakage. Required double patterning. Double patterning means more masks mean more expense up front and during manufacturing. It actually cost more per transistor than 28nm. What was the point, really?
That is pretty much the mess were are in now. Can't significantly increase clock rate. Can't throw gates at the problem and wouldn't really know what to do with the gates if we had them. Finfets temporarily tamed power but are only available in nodes hobbled by the need for multi-patterning.
My SSD based laptop boots a lot faster than Windows 3.1.
As far as "planned obsolescence", I'm running Windows 10 on a Core 2 Duo 2.66Ghz laptop with 4Gb of RAM - a computer that was first sold in 2009. It runs my Plex Server and my PlexConnect server.
My mom still uses my 2006 era Mac Mini (Core Duo 1.66) with Windows 7, Office, and Chrome. It has 1.5Gb or RAM. When I go home and use it, it's not unusable as long as you don't try to run too many things at once.
My secondary laptop that I keep upstairs is a circa 2009 2Ghz Pentium Dual Core with 4Gb of RAM running Windows 7. In day to day use, the only thing wrong with it is a battery that won't hold a charge.
You can accuse MS of a lot of things, but not optimizing Windows to run well on fairly old hardware isn't one.
For a long time, Intel and Microsoft Windows have rules the computing world. The platform has been at the bottom, Intel's instruction set architecture.
Intel leaped from 16-bit to 32-bit architecture and then from 32-bit to 64-bit but the basic execution model remains the same. Most of the advances that Intel have done from the Pentium onwards in the early '90s have been stopgaps to get as much out of the execution model, but still being limited by it.
There are other processors out there, DSPs, that are much faster than x86 at specialized tasks by making them pipelined and parallel. GPUs could be seen as massively parallel DSPs.
But raw computing power is not the problem. The problem is to run general-purpose code well - and general-purpose code has many branches between code paths and that can't be parallelized.
A company called Mill Computing is working on a general-purpose CPU architecture inspired by DSPs and from what they think that the Intel IA-64 (Itanium) should have been.
By being vastly different in several significant ways from x86, they claim to be able to achieve a significantly higher performance per watt and performance per clock overall than Intel and AMD's x86.
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
The CIV games make young minds think that technological breakthroughs are simply a matter of money and time, then BANG tech advance!
Somebody needs to start airing "Connections" again: http://topdocumentaryfilms.com...
The gates are now so small that the electron wave function has a pretty high probability of being "on the other side" of the gate. As gates shrink, leakage power goes up very rapidly. Even when they're "off", the gates are consuming too much power (leaking it to ground.)
Also, think about 5 Ghz, IBM's fastest chips. At 5 Ghz, the clock speed is 200 picoseconds, and a 10 deep pipeline can allocate about 20 ps to each gate transition. That's a lot to ask, given that resistance and capacitance don't scale down linearly with dimensions. You also have to populate your chip with a lot of decoupling capacitors in order to hold the charge locally for each transition (because you can't get the power from off chip in 20 ps.) To fight the increased RC load (proportionally) you're putting in more buffers (big amplifiers).
As if that weren't enough, you have the fact that a 14 nm gate is about 20 silicon atoms across. When you start doping the substrate, your actual behavior is all over the place because one or two more dopant atoms represent a 10-20% shift, up or down (total shifts of 40-50%.)
So, your gates are too small, they all behave differently, they have to drive a relatively larger load, and the suckers are too hot.
Intel is up to their shady tactics again with AMD's new Ryzen release. Maybe not out right paying off computer makers, just now they are sponsoring reviewers. The reviewers jump through all kinds of hoops to make sure that Intel is on top of the benchmark graphics and read like a Intel marketing brochure. None of the reviewers disclose that they are sponsored by Intel.
Examples of oddities from reviewers that are sponsored by Intel.
1) Tom's Hardware: Complains about the power consumption being higher than spec, leaves out that the result was from a overclocked test and an MSI board that has an additional CPU power.
2) GamersNexus (one worst of them)
a) Had to compared the 1800x to 6 different Intel processors that were overclocked with the 6900k overclocked by 700Mhz.
b) Only one AMD processor was OC by -100Mhz(yep) . There OC vs stock were almost exactly same.
c) Makes the 6900k pop on the top of the benchmarks.
d)1800X only loses 6 vs 8 to the Intel 6900k at stock speeds. With only 2 benchmarks with the 1800x losing by more than 7fps.
e)Pretty much all benchmarks by the same author never included OC tests, but suddenly he had to compare it to 6 different OC benchmarks. http://www.gamersnexus.net/gam... http://www.gamersnexus.net/gam...
f) Out right lied saying AMD told him not to benchmark Ryzen at 1920x1080. AMD just asked him to benchmark at multiple resolutions , not just 1080P.
> trying to teach some of the programmers out there how to program effectively on the various parallel platforms is harder than trying to alter physics.
Which could also be phrased as:
So far, many of the parallel platforms available are much harder to learn.
Programmers can and do learn new and different ways of working, provided that the new ways don't suck.
C, Java, etc are all imperative, scalar and object based languages. SQL is a completely different paradigm, declarative and set-based. In other words, in most programming languages the programmer tells the computer how to do some task, with some value. In SQL, the programmer tells the computer what the result must be - without specifying how to do it, and all fundamental operations work on sets, not individual values. Yet most programmers can ans often do learn the declarative, set-based way of programming just as well as they learn the classic imperative way. They learn two very different ways of thinking and programming, because SQL is reasonably good - it's quite learnable, with or without understanding the underlying mathematical concepts.
There's no fundamental reason you can't have a parallel programming language or library for general purpose programming that's roughly as easy to use as SQL. In fact, SQL may point the way in many respects - besides being a learnable paradigm, it's fundamentally parallelizable precisely because the fundamental operations all use sets as input and output. All the major operations could easily be completely parallelized behind the scenes and the user (programmer) wouldn't have to know or care.
Maybe that's the way to go, since we know programmers can and do use sets - introduce a set-based general purpose language. To avoid leading programmers into temptation, the language should have no loop constructs. With no capability to run this:
foreach blah in group {
result[i++] = do_stuff(blah);
}
programmers will quickly learn to instead write:
results = do_stuff(group);
But you don't have to look to future software for this.
ASIC design languages create designs that are explicitly parallel, and they do it easily. Sure, there are synchronizations that have to happen, but that may not apply to much of the design. They are explictly event-oriented, and combinational (When this event occurs, do one of the following things depending on the state of these other two signal). I have sometimes been amazed at how quickly, and in how small a description. and with a full test suite, a good digital designer can implement some algorithms compared with an embedded 'C' programmer.
And the worms ate into his brain.
Well the C64 didn't do really do anything on boot - mostly initialize the 40 character x 25 line display and jump to Basic and start executing. The kernal was custom written for one hardware config, didn't work with thousands of different pieces of hardware. No internet, no services at all to run (because no multi-threading). Those machines were extremely simple, and really can't be compared to today's Mac, Linux, or Windows OS's.
But modern machines are about 10000x faster. Needless complexity aside, it's just not that much more complicated. Whatever is hardware-specific, cook that up when the hardware changes - how often does that happen? - and park it ready for fast boot again.
We just suck at "fast".
Socialism: a lie told by totalitarians and believed by fools.
My girlfriend asked what laptop she should buy. There was a time when I would have had all kinds of answers, maybe even fixup her old laptop with Linux or something to squeeze a couple more years out of it. That was then.
To save trouble, I just gave her a Chromebook. I know very little about them. But I know they just work, at a fraction of the cost of anything else. She can check her work schedule, do online shopping, watch Netflix, etc. And I don't have to be bothered!
I don't have to mansplain to her, figure out why her network connection wasn't working, or how to install extensions so she can browse safely, or one of a million things that happen when an ordinary person uses a real computer and real OS. I could have given her a top of the line, tricked out Dell, or Asus, or whatever. She wouldn't have been any happier or any more satisfied.
So now my stock answer when anyone (other than a STEM student) asks about what computer they should buy, my answer is Chromebook.:
For certain operations, AVX made a huge difference. AVX2 made an even huge-r difference. Depending on what you're doing, you can see a 2x to 10x speedup on the outside vs. using a chip without AVX2 with similar performance characteristics.
My Other Computer Is A Data General Nova III.
There have been many breakthroughs in the PC industry, incredibly clever inventions which allowed things to move forward. And that's the thing, the smartest things in the industry don't make for a huge processing leap, they enable making progress at all. Each of these developments take years. Ideas may be simple, but implementing them, especially at the level required for mass production, is hard. Each development also requires more accurate tools. Also, complexity is now so high, that, as imgod2u said, even a huge change in some part leads to an overall small change.
So as others have said, physics, but I think the above is a more nuanced answer. I remember when people said that it wouldn't be possible to make transistors under a micron in size. The very fact that we've reached so far is miraculous.
It happened about ten years ago with the rise of GPUs for general purpose computing. Suddenly we could do a lot of things 10-100 times faster than before. You program GPUs really differently than CPUs, so we had to rewrite a lot of code and design new algorithms. But the benefit was huge.
It may be happening again with specialized chips for deep learning, like Google's TPU. These chips are designed for just one class of applications, but it's a really important class, and they can be 10x faster or more efficient for those applications.
There've been other times when a new generation brought a sudden major improvement in speed, like with vector units or multicore CPUs. But always at the cost of having to rewrite how your code works.
Now if you want new chips that work just like the old ones and run the same programs as before, just 10x faster, sorry. That isn't likely to happen. Huge jumps like that require major changes of approach.
"I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."
It did indeed have a construct like:
Unfortunately, it was not American.
Sent from my ASR33 using ASCII
I think the real issue is, semiconductors are so competitive, the current shipping product is always very close to the state of the manufacturing and physics arts. Intel, AMD, nVidia, Samsung, Toshiba, Apple, and others spend billions pushing the processes and architectures to the limit in every product so it stays competitive as long as possible.
To get a 4x or 8x improvement in size, power, or speed would imply there's a revolutionary way to do things that we just don't quite know yet. And it better be something which can be quickly turned to production because Moore's Law hasn't stopped yet. If you have a 4x improvement idea but it takes five years to release, it won't get funded. Plain CMOS silicon has too good a chance of catching up.
There's plenty of times people rolled the dice on processor moon shots. I was at HP when Itanium was first developed (~95). We thought we'd have working silicon in a few years (~98 or 99) at the astounding clock rate of 500 MHz (oh, and that was potentially retiring something like 6 to 12 instructions per cycle, I forget the details). This was when a good Pentium processor ran at around 45 MHz. We thought Itanium was going to be so frickin' fast there was no way Intel could compete. Then AMD started a clock rate war, x86 got faster really fast, Itanium took much longer to produce than we anticipated, and the rest was history.
I think the bottom line is, it's really hard to produce a system which really is even 2x faster than the competition. 4x is incredible and 8x probably has never been done.
As an analogy, consider cars and mileage. My car, a diesel Passat (which shortly will not be road legal :() actually exceeds 50 MPG on a good day. What would it take to make a car which gets 100 MPG with a 600 mile range? How about 200 MPG? With no compromises? And a sales price of $28k? It's pretty hard to imagine.
Central high power cloud machines are just a disaster waiting to happen, how many times does this have to be proven.
Once would be a good start. Do you really think that people are not designing fault-tolerant network infrastructure?
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
Laziness is a virtue in a programmer.
The whole point of this profession is to save labor. That includes programmer labor, especially because it's an expensive commodity.
I don't know who has mod points today but this comment is frankly ridiculous.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
Maybe that's the way to go, since we know programmers can and do use sets - introduce a set-based general purpose language. To avoid leading programmers into temptation, the language should have no loop constructs. With no capability to run this: foreach blah in group { result[i++] = do_stuff(blah); }
programmers will quickly learn to instead write: results = do_stuff(group);
I agree, but I think you've taken it a step too far here. Look back at maths and how things like sigma summation and similar things like the product function work. Because of the mathematical properties of these, they are order independent, and inherently parallelisable.
Eliminating loops doesn't mean eliminating a "foreach" -- it just means treating each instance of the block as its own scope, and ensuring that no instance can access the variables of another instance. (Talking "instances" instead of "iterations" immediately says it's not a logical loop, even if the computer running it realises it as such simply due to lack of parallel capacity.)
The problem with this is that you then have to combine the results, so you either need to treat the whole block as an inline procedure and end with a return statement, or you treat the block as a function, and now we're into functional programming.
Basically, this sigma-style programming would be logically equivalent to carrying out a map followed by a reduce... and map-reduce has become such an important concept in server programming specifically because of this inherent parallelism. The thing is that current map-reduce renders code to the programmer in a totally different style to what they're used to. There are parallel programming environments that do render parallelised blocks in a C-inspired way, and surely that's the most obvious approach...?
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'