David Patterson Says It's Time for New Computer Architectures and Software Languages (ieee.org)

Tekla S. Perry, writing for IEEE Spectrum: David Patterson -- University of California professor, Google engineer, and RISC pioneer -- says there's no better time than now to be a computer architect. That's because Moore's Law really is over, he says : "We are now a factor of 15 behind where we should be if Moore's Law were still operative. We are in the post -- Moore's Law era." This means, Patterson told engineers attending the 2018 @Scale Conference held in San Jose last week, that "we're at the end of the performance scaling that we are used to. When performance doubled every 18 months, people would throw out their desktop computers that were working fine because a friend's new computer was so much faster." But last year, he said, "single program performance only grew 3 percent, so it's doubling every 20 years. If you are just sitting there waiting for chips to get faster, you are going to have to wait a long time."

Comments

so go do it, David

[Anonymous Coward]

I can say dumb shit too, but that does not make it happen.

It is time for the world to give me ten million dollars

Re:so go do it, David

[lgw]

I would say that architecture is changing, at least for production systems. It's all about scaling horizontally instead of vertically. Sure, individual cores aren't much faster, but a couple years ago I launched 30,000 cores in two minutes on AWS, and about a year ago EC2 Spot announced a million-core stunt of some sort.

A million cores from COTS technology is a lot of performance.

Re:so go do it, David

[ranton]

I am pretty sure David Patterson is out there doing it. He is a professor in the field who has accomplished plenty. He is 70 now and is likely past his academic prime, so now he is doing what he should be doing at this time in his career: teaching, mentoring, and inspiring the next generation.

Re: so go do it, David

[Anonymous Coward]

Teach by example. Show me an architecture that would make me want it. With C++ as a platform language, not stupid shit like java, ruby etc.

Re: so go do it, David

[Anonymous Coward]

Rust? Go?

Re:so go do it, David

[gweihir]

More cores are worthless for most tasks. Takes some actual knowledge to see that though.

Re: so go do it, David

[Anon-Admin]

CLR

Re:so go do it, David

[gweihir]

Sounds more to me that he cannot let go of the old, failed ideas and face the reality that there is no silver bullet. There is plenty of aging CS professors around with that problem.

Re: so go do it, David

[Anonymous Coward]

He already did that being a risc pioneer. Didn't you even skim the summary so your trolling would be relevant? No, you didn't.

Re: so go do it, David

[ElitistWhiner]

The oxymoron here is that David uses hardware performance to substantiate his cliam.

The computer revolution went askew taking the hardware track leaving software to rot in 1960â(TM)s state of the art computer science.

The next revolution is soft not hard.

Re:so go do it, David

[lgw]

You just need to be smart enough to learn how to solve your problems with more cores!

My, these assertions are easy to make.

Re: so go do it, David

[Anonymous Coward]

I like elixir and crystal.

Re:so go do it, David

[jythie]

More cores are worthless for many implementations of most tasks, which is not the same as being worthless for the task itself.

Re:so go do it, David

[Anonymous Coward]

I can say dumb shit too...

I have a sneaking feeling this happens often.

Re:so go do it, David

[Anonymous Coward]

You probably only ever say dumb shit. Judging by your post above.

David Patterson has been "going and doing it" probably since before you were born.

Do check out his life story and learn something.

Re: so go do it, David

[Aighearach]

My whole life the main factor leading to people accepting sucky software is that the hardware is always getting better, and by the time they ship it it runs "fast enough" on the new hardware.

I've been anticipating this for decades; eventually computing power is "good enough" that people start actually trying to write good software. In my view the hardware is at that point, and time is ripe for software changes. And this will lead to tool improvements, to be sure. Architectures are likely to change, because a big part of what goes into existing systems is exactly this desire for the architecture to be relevant for a predetermined amount of time! If the hardware isn't improving and you can't just sell people the new version every few years, that radically changes the design considerations for the whole system. So far, that hasn't happened at the consumer level, and I don't know which changes will be successful, but there are likely to be radical changes in system architecture as companies start to design systems for much longer life.

I will make one specific prognostication: As new hardware architectures are introduced, more of the software will be pushed back onto ROMs, and OS kernels will act more like microcontroller libraries where you use system functions that on more expensive hardware is implemented in ROM, and on cheaper hardware the same code gets copied to RAM (as is the case for most of the system now)

Right now, and historically, audio/video subsystems sometimes have "hardware acceleration," certain things like floating point hardware are not always available, some optical scanners have to have their firmware copied from the host driver, some laptops require custom drivers because of custom hardware support/acceleration of various subsystems, and there is no general mechanism to manage any of this. Each subsystem might have a locally-standardized interface, but there is nothing general for those classes of situations. Or at least, to the extent that there is, it is only within the C compilers that it exists. I predict much greater convergence in how these different subsystems are defined and how they interact. Return of the Thick Client! Except the cheap version will be a compatible thin client. And each subsystem will be able to be implemented as hardware, local software, or cloud services.

Re:so go do it, David

[Anonymous Coward]

Sounds to me like you have no idea what you are talking about.

Patterson may be aging but his "old failed ideas" are now very successfully used all over the place. Your mobile phone for example.

He has also been working recently on Google neural network devices.

He would be the first to admit that we need a new approach to make progress in the post Moore's law era.

Re:so go do it, David

[Anonymous Coward]

Silver bullet as in "one size fits all" solution? The opportunity he specifically spoke about was to tailor solutions to domains, rather than keep on using general purpose shit.

Re:so go do it, David

[Anonymous Coward]

Research back in the late 90's suggested that most SPEC benchmarks could effectively use between 2.5 - 4 cores. Is that legit enough for you?

Re: so go do it, David

[cpurdy]

Teach by example. Show me an architecture that would make me want it. With C++ as a platform language, not stupid shit like java, ruby etc.

When you begin an ignorant missive with a set of requirements that are in direct opposition to your stated end goal, how do you expect someone to respond?

Seriously, your request is like someone asking for better ASCII porn in 2018.

If you want to be taken seriously in computer science, start by not sucking up to the worst language since BrainFuck.

Re:so go do it, David

[lgw]

And if your system has more than 1 user (at the same time)?

Re: so go do it, David

[K. S. Kyosuke]

Show me an architecture that would make me want it. With C++ as a platform language

"Show me a new vehicle to replace the carriage. It has to include a horse."

Re: so go do it, David

[Anonymous Coward]

> "Show me a new vehicle to replace the carriage. It has to include a horse."

https://www.crossroadstrailers.com/blog/wp-content/uploads/2016/08/iStock_10259053_LARGE.jpg

Re: so go do it, David

[Anonymous Coward]

C++ is the best language period. You scripto-imbeciles out MIT need to die.

Re:so go do it, David

[Anonymous Coward]

I am pretty sure David Patterson is out there doing it. He is a professor in the field who has accomplished plenty. He is 70 now and is likely past his academic prime, so now he is doing what he should be doing at this time in his career: teaching, mentoring, and inspiring the next generation.

If he is past his academic prime, then he definitely should not be teaching, at least not as a professor at a college or university.

Re: so go do it, David

[Anonymous Coward]

Assembly is laughing at you.

Re: so go do it, David

[Anonymous Coward]

I've been anticipating this for decades; eventually computing power is "good enough" that people start actually trying to write good software. In my view the hardware is at that point, and time is ripe for software changes.

The transition to cloud services which are essentially the old time-sharing model of computing might herald a resurgence of low-cost computers, primarily smartphones, tablets, and most notably notebooks) which are simple to understand, provide a command shell environment and applications written in JavaScript. The client end application is merely an interface to the remote computing system that does the heavy lifting. The server end (cloud services, in-house or external) performs the data processing tasks whether it be a statistical modelling process, a photograph editing process, or a file storage process, etc.

These days I use my notebook computer running a command shell from which I can use vim, screen, Docker containers, etc. In other words most of my productive activities. Realistically, I still need and use a GUI desktop to run Google Chrome to access various courses and training that I am taking at any given time. If you know of a framebuffer video player capable of handling streaming videos with audio and smooth playback, please let me know.

Re:so go do it, David

[MichaelSmith]

More cores are worthless for most tasks.

Thats the whole point of the article. Getting more work out of your cores.

Re: so go do it, David

[Anonymous Coward]

We need hardware native Flash and Actionscript 3.0 as the base of all computing!

Re: so go do it, David

[Anonymous Coward]

I'll be happy if they can stop ballooning various programs and games to over 80gb when the same thing could be accomplished by less than a third of the space by using proper programming and file compression.

Re: so go do it, David

[Anonymous Coward]

What on earth are you talking about? Everything runs on hardware. Every VM. Every container. All of it. Every bit.

Are you suggesting that software will, you know, just take flight and run in actual, real clouds?

Re: so go do it, David

[Anonymous Coward]

UEFI is actually supposed to be capable of much of that, with UEFI drivers providing services the way that BIOS extensions did to 16-bit OSes. The real problem is that this is basically a death knell for open source kernel drivers and encourages artificial market segmentation by driver contents rather than silicon capabilities.

Re: so go do it, David

[k6mfw]

I like how you took this car analogy, I posted this little thread to a friend's FB page. She really likes horses and also collects horse analogies like computer people collect car analogies.

Re: so go do it, David

[Anonymous Coward]

Show me a new vehicle to replace the carriage. It has to fit the infrastructure we have-- that is, it must be no wider than two horses and must be affordable by the average person. Because otherwise nobody will be able to go everywhere they want to in it and nobody would be able to afford to buy it anyway.

Fixed it for you.

Re: so go do it, David

[Anonymous Coward]

What we need is More Agile(tm) Now!!

Re: so go do it, David

[Anonymous Coward]

Down with education!!

Re: so go do it, David

[Anonymous Coward]

Nice analogy

Re:so go do it, David

[Anonymous Coward]

Uh, that's exactly what he's doing and working on while you sit there whining about it.

Re: so go do it, David

[Anonymous Coward]

I thought this was pretty fucking funny

Re: so go do it, David

[Anonymous Coward]

Bullshit. 50% of his prime kicks 90%of the pikers out there at their prime

Re:so go do it, David

[gweihir]

You seem to know nothing about algorithm performance analysis. Please stop claiming nonsense. You are just disgracing yourself.

The fact of the matter is that for many important classes of algorithms, using more cores slows things down and that is a hard, theoretical fact, so there is no way around it. For many others, you get speed-ups per additional core that are so bad that the communication overhead kills all advantages. This has been known for something like 50 years or longer.

Re:so go do it, David

[gweihir]

Then they each get less performance than if they had their own computer due to various bottle-necks. That is not scaling.

Re:so go do it, David

[gweihir]

Yes, so? That is what you say and it has nothing to do whith what I just said. For most tasks, it does not matter how good the implementation is, more cores do not help.

Re:so go do it, David

[gweihir]

The article is just dumb.

Re:so go do it, David

[lgw]

You don't ... do backend software, do you.

Re:so go do it, David

[skids]

Moreover, compared to on-chip or at least on-board multiprocessing, the network is really, really slow. Seriously long-ass latency. So cloud scaling has more limits on the number of algorithms for which it is actually useful than even very simple highly parallel architectures.

Re:so go do it, David

[MichaelSmith]

But this is the thing. I work on an asynchronous back end application written in javascript (stupid design decision, I wasn't around at the time). It uses all of one core and nothing from other cores so there is little I can do to give it more resources to work on. If the JS virtual machine could cope with working across multiple cores, then all would be good.

Thats what this article is about, and its a good question.

Re: so go do it, David

[Anonymous Coward]

"haha, women are property and saying that I defaced your property with my penis is insulting, be offended you cuck!"

What even is the point of comments like that, other than to show us that you're the biggest idiot on the site?

Re: so go do it, David

[bn-7bc]

Yes but would you still get 60+fps in 4k (numbers made up), here is the thing compared to CPU and gpu storrage is relatively cheap and with ssds fast enugh to not be a major pitam so the fame deva trade storrage for performance, is this right or wrong? Not shore, what do you think? I agree that the initial download of 80GB is a rather boring process (esp if you are stuck on a pipe that is nerrower than it should be)

Re:so go do it, David

[gweihir]

Actually, that is something that was solved a few decades ago. There is no need for anything new here, the only need would be that the people that wrote this JS engine knew the state-of-the-art. That is if there was no good reason to make this engine single-thread. Making it multi-threaded comes with a host of well-known problems, that may or may not make it worth it. In particular, single-threaded applications get slowed down and garbage-collections becomes much more difficult to do.

Re: so go do it, David

[Megol]

No, by requiring C++ there is no new software. Not reading linked articles is standard here, not reading the blurb is normal too, however not even reading the title?

Re: so go do it, David

[Anonymous Coward]

Academic Prime, one of the lesser known transformers.

Re:so go do it, David

[garethjrowlands]

I don't think you properly read the post to which you are replying. Their first sentence wasn't meant to be read literally, as their second sentence makes clear. They were simply pointing out that it's easy to make blanket assertions that aren't really true. The particular assertion-that's-not-really-true is the following:

> More cores are worthless for most tasks.

This statement would be _definitely_ true if you'd said, "more cores are worthless for _many_ tasks". Now it's far too easy to assume that everyone on the Internet is a total idiot. But the truth is that many people aren't (well we all are, some of the time). It's really best to give people the benefit of the doubt.

In particular, if someone claims that a million core is a lot of performance, it doesn't necessarily mean they don't know what can and cannot be done with those cores. Especially if they describe spinning up lots of cores on AWS as a stunt.

Google, Amazon. Netflix and the people who build and use super-computing clusters all use lots of cores. And they know what they're doing.

In another post, you also said this:

> compared to on-chip or at least on-board multiprocessing, the network is really, really slow

This is, of course, true. But it's not the whole story. The "network" and "on-board" aren't quite as distinct concepts as they once were. Especially in a datacentre or super-computing cluster. In practice, network latencies are often surprisingly small. (And, conversely, the latency within a CPU or board is often surprisingly high - they're full of networks these days) The plain fact is that super-computing clusters (and the datacentres they resemble) get more work done than if they had a single CPU.

We'd all like faster cores. But the people scaling horizontally are not idiots.

Re:so go do it, David

[Anonymous Coward]

compared to on-chip or at least on-board multiprocessing, the network is really, really slow

This is, of course, true. But it's not the whole story. The "network" and "on-board" aren't quite as distinct concepts as they once were.

I used to explain it to fellow students with a cooking analogy:

The CPU registers are like your cutting board.
The on-chip cache is like your countertop.
The L2 cache is like your cupboards.
The main memory is like your pantry/cellar.
The disk is like running to the store.
The network is like running to the store in another town.

When you're cooking, you don't want to keep running to the store in another town when you need a tomato or onion!

Re: so go do it, David

[tanimislam]

You mean like a Beowulf Cluster?

Re:so go do it, David

[Bengie]

The fact of the matter is that for many important classes of algorithms, using more cores slows things down and that is a hard, theoretical fact

While you are technically correct, there are trade-offs that can be made. Many programmers limit themselves to preserving ordering and never losing data. There are cases where a lossy or non-order preserving alternative algorithm can have near perfect linear scaling, but you need to make sure you system is designed and can fundamentally accept this trade-off.

A simple example that I've done. I wrote a high concurrency library that had an estimated time to completion. The way it did that was to update the average rate of work units processed and the remaining. When I did proper locking, the fine grained work units were causing high contention, resulting a maximum of 80-90% utilization on a quad core HT CPU. I removed the locks and just optimistically checked a variable padded to its own cache-line. If the data-structure was in use, just don't update and discard the timing results of the current work unit, and if it wasn't in use, then flag it in use and update. If a race condition occurred and two updates happened at the same time, it didn't matter because the the values were designed to not be accumulative and would approach correct.

In the end, there was an ever so slight increase of variability in the presented ETC, but it was still capable of predicting what time it would finish within 1% of error within the first few minutes of a multi-hour run, and now it was able to scale to 99% CPU on a 32core HT server. Not that the increased variability mattered much because there was already a natural amount of minor variability due to available computational resources. In short, the increased variability was measurably different, but within the std-dev of existing uncontrollable fluctuations.

Moral of this store. In concurrency, perfect can be the enemy of good.

Re:so go do it, David

[Bengie]

Spin up several worker nodes and load balance?

Re:so go do it, David

[Bengie]

The answer to the problem is to let people who can do concurrency well, have a say in the architecture and design of systems. The problem is this whole top-down management style. It needs to be bi-directional. Most of your talent is in the trenches and it's a recipe for disaster to tell your talent how to do their job when they see the flaws in the designs. No one person can both be technically fluent and have the communication skills required to be the perfect lead.

Programming is a huge industry. People saying "concurrency is hard" is akin to a typical person saying calculus is hard. Some people find it easy. But don't expect people who find calculus easy to find communication easy.

Re:so go do it, David

[MichaelSmith]

Only works if the application is amenable to doing that. In this case its not, short of a complete rewrite. The rewrite is under way so yeah some support for parallel processing at the application level can work as a last resort.

Re: so go do it, David

[Anonymous Coward]

Rust is sensible, but Go is slow as a wet week.

Re: so go do it, David

[Anonymous Coward]

Many times networks can be faster than diask these days.

Re:so go do it, David

[lsatenstein]

I am pretty sure David Patterson is out there doing it. He is a professor in the field who has accomplished plenty. He is 70 now and is likely past his academic prime, so now he is doing what he should be doing at this time in his career: teaching, mentoring, and inspiring the next generation.

How can you say, "Past your prime". I am 80 and doing hardware and software design. I am inspired and I enspire others.

For the desktop, what I foresee is migration to loosely coupled systems. Don't need 32cpus on a chip, instead have a half dozen sub-systems with multi-core cpus. My next major desktop should have a system(with it's cpu) for file-IO, another for security, another for user interface and perhaps more specialized subsystems. Each system would be independent of the other and communicate between each other via some fibre optic interface

Re: so go do it, David

[Anonymous Coward]

your mother was a sow and your father stank of elderberries

Re: so go do it, David

[Anonymous Coward]

Iâ(TM)m at UC Berkeley right now studying RISC-V ISA, perhaps I am just drinking the kool-aid but I think itâ(TM)s really exciting stuff. The assembly is surprisingly readable, compared to MIPS or x86 ( Although it is very similar to mips). I canâ(TM)t wait for the industry to see more adoption of this open technology, and advance it even further!

Re: so go do it, David

[Anonymous Coward]

> Many times networks can be faster than diask these days.

True, but raw latency isn't the whole story. A typical use case is going to be accessing data on a remote disk anyway, so you have the network overhead on top of the disk latency.

Also, accessing data over the Internet is going to be many times slower than within a local network.

Re: so go do it, David

[tigersha]

Does not compose, except at the highest level of the application. The curse of NodeJS

Re: so go do it, David

[tigersha]

I like the BEAM, but elixir is a badly designed language. Who designs functional languages without algebraic sum types and pattern matching!?

Re: so go do it, David

[tigersha]

And hardware instructions for CSS since the machine animating a doodah while waiting for the disk in any case.

Re: so go do it, David

[tigersha]

Patterson is a CPU architecture God.

Re: so go do it, David

[Anonymous Coward]

It should come as no surprise that Moore's Law isn't holding, that is currently we are at 3 years instead of 18 months. The reason is that each technological development follows an S curve, this includes computer chips, but also includes ( or should include ) software, and every other piece of technology. It might be that the entire technological development curve over the world's history and may including life itself and all technologies is on an S curve and at some distant point in the future it will all hit a wall where it will go no further do to limitations in the laws of physics unless we find a way to break through these laws or that there is some set of laws that include as a subset the laws of physics as we know it, (perhaps the universal laws that govern quantum mechanics in multidimensional space time or something like that, which probably means the technological development curve actually looks more like a series of S curves in the shape of a set of stairs.

Re: so go do it, David

[Agripa]

Teach by example. Show me an architecture that would make me want it. With C++ as a platform language, not stupid shit like java, ruby etc.

If you want it linked with C++ (or C) as C++ is, then you have already failed.

On the C++ side, how is it that multiplying two INTs produces an INT?

On the architecture side, why doesn't each register include stateful flags?

Re: so go do it, David

[Anonymous Coward]

Agile(TM) is not the answer! Doesn't scale horizontally. Besides, it is old paradigm and we need an order of magnitude greater than Agile is today.

Re: so go do it, David

[Anonymous Coward]

How old are you? Multi-Tasking benefits greatly from multi-threading on multiple cores.

Re:so go do it, David

[lgw]

Sure, "many important classes". And the rest? You know, the stuff almost every business does?

Here's an example: lets say you want to render the next Pixar movie. At what point do more cores stop helping? For reference, you need to render 150,000 frames, each with maybe a half dozen independently rendered effects that are later composited. Could you find a way to use 1 million cores?

Here's an example: lets say you run a web service that gets more than 10,000 hits per second, but does nothing computationally intensive for each request, beyond the normal crypto. Do you care how fast your cores are, or how many cores you have?

Yeah, yeah, academic calculations are great and all, but most of the world need to get shit done.

Re:so go do it, David

[lgw]

So, have one server for each user. Easy. Realistically, you can get away with 100 or 1000 users on each server, as most real-world tasks aren't computationally intensive, and a whole lot of users can wait idly for I/O to finish.

Re:so go do it, David

[ranton]

How can you say, "Past your prime". I am 80 and doing hardware and software design. I am inspired and I enspire others.

Past your prime does not mean useless. Tom Brady is past his prime but still one of the best quarterbacks in the NFL. Humans peak physically earlier than we peak mentally, but both still happen. And it is long before we reach 80. Not all aspects of mental acuity peak; vocabulary for instance steadily climbs through age, while working memory peaks in our mid-30's.

Re:so go do it, David

[Anonymous Coward]

Patterson is a co-author of this classic text:

Computer Architecture: A Quantitative Approach

If you're serious about computer science, you should have it and know it.

New architectures

[Anonymous Coward]

Hey, I know. We should use asychhronous techniques! At both the circuit and the architecture level. (P.S. This is sarcasm, which students of Digital Logic and Computer Engineering may find amusing.)

Re:New architectures

[lgw]

Hey, I know. We should use asychhronous techniques! At both the circuit and the architecture level. (P.S. This is sarcasm, which students of Digital Logic and Computer Engineering may find amusing.)

The other half of the joke is that async I/O was the big new feature of a recent C# version, which means it will be the hot new thing in Java in another couple of years.

Re:New architectures

[laie_techie]

Hey, I know. We should use asychhronous techniques! At both the circuit and the architecture level. (P.S. This is sarcasm, which students of Digital Logic and Computer Engineering may find amusing.)

The other half of the joke is that async I/O was the big new feature of a recent C# version, which means it will be the hot new thing in Java in another couple of years.

Java NIO (Non-blocking I/O) was introduced in Java 4 (2002).

Re:New architectures

[gweihir]

Boy, do I miss the old MC68000, where I could just look up how long something takes and could do actually fully synchronous coding for a significant performance boost.

Re: New architectures

[Anonymous Coward]

You ignorant piece of shit. Asynchronous io has been in java for almost 2 fucking decades. Drop dead

Re: New architectures

[Anonymous Coward]

Nonblocking IO has no relationship to this joke. See me after class.

Re: New architectures

[Anonymous Coward]

Who is hurting you?

Re:New architectures

[lgw]

That will in no way prevent it from being the hot new thing in Java in a couple of years. Probably with all new libraries.

Re:New architectures

[jythie]

Java NIOng!

Re: New architectures

[Anonymous Coward]

Mom's had me locked up in the basement ever since dad died. All that the AOL parental controls allow me to access are slashdot, reddit, and yahoo!. Get off my toes, I'm claustrophobic.

Re:New architectures

[Aighearach]

Why miss what you can still have? Starting at under $33!

https://www.mouser.com/Product...

But I'm not sure you'd have any advantage over a $5 ARM SoC.

Re:New architectures

[ArchieBunker]

Study the AS/400 architecture. It does things very differently.

Re: New architectures

[MichaelSmith]

reddit

Plenty of porn then.

Re: New architectures

[tigersha]

NNIO

Re: New architectures

[tigersha]

Which is is why it is dying...

Re:New architectures

[Agripa]

The other half of the joke is that async I/O was the big new feature of a recent C# version, which means it will be the hot new thing in Java in another couple of years.

Java NIO (Non-blocking I/O) was introduced in Java 4 (2002).

Non-blocking I/O and asynchronous I/O are not the same.

http://www.programmr.com/blogs...

Re:New architectures

[laie_techie]

The other half of the joke is that async I/O was the big new feature of a recent C# version, which means it will be the hot new thing in Java in another couple of years.

Java NIO (Non-blocking I/O) was introduced in Java 4 (2002).

Non-blocking I/O and asynchronous I/O are not the same.

http://www.programmr.com/blogs...

Java NIO also introduces Non-blocking IO

Java IO's various streams are blocking. That means, that when a thread invokes a read() or write(), that thread is blocked until there is some data to read, or the data is fully written. The thread can do nothing else in the meantime.

Java NIO's non-blocking mode enables a thread to request reading data from a channel, and only get what is currently available, or nothing at all, if no data is currently available. Rather than remain blocked until data becomes available for reading, the thread can go on with something else.

The same is true for non-blocking writing. A thread can request that some data be written to a channel, but not wait for it to be fully written. The thread can then go on and do something else in the mean time.

What threads spend their idle time on when not blocked in IO calls, is usually performing IO on other channels in the meantime. That is, a single thread can now manage multiple channels of input and output.

Waiting for chips?

[The Original CDR]

When your computer is fast enough to do everything that you need to get done in a reasonable amount of time, do you really need faster chips?

Re:Waiting for chips?

[Jogar the Barbarian]

Depends on what your definition of "need" is. For example, I could say I need to run Minecraft with 220 mods, at 30 FPS, with hundreds of machine blocks. (with an i7-7700k I usually get around 11-12)

Re:Waiting for chips?

[The Original CDR]

Consumer software, chiefly Internet browsing and Microsoft Office. I can now do that across an iPhone, iPad and a ten-year-old gamining PC. If I want the exact same performance on my gaming PC with newer hardware, I could upgrade to a new motherboard, processor and RAM for $200 (RAM being the most expensive part). More money will just buy more cores. This isn't like 20 years ago where you needed a faster system to keep up with Windows. If anything, software is lagging behind the hardware.

Re:Waiting for chips?

[Anonymous Coward]

Did anyone read this comment and think of "dipshit" and do a double take? ~ CaptainDork

Re:Waiting for chips?

[squiggleslash]

You know, I thought my Amiga 500+ was pretty snappy even in 1995.

While we complain about bloat and poor programming, the reality is that most of the performance improvements we've seen over the history of microcomputing has been directed at creating entirely new applications that weren't feasible with the older technology. That 500+ could never run a modern web browser no matter how efficiently it was built. As for video games...

Re: Waiting for chips?

[Anonymous Coward]

Absolutely. Faster chips means you can eventually make them smaller, hopefully take up less energy.

Faster chips means they can handle better compression and decompression algorithms. That in turn means better video quality for the same bandwidth.

Re:Waiting for chips?

[Anonymous Coward]

As the other indicated, it depends on what you mean by need. It also depends a great deal on what you're doing. Unfortunately, Gates law of bloat continues unabated as projects add pointless bullshit without considering how to optimize for it and how much of it is really just unnecessary bloat. Just because I have 16gb of RAM, does not mean that a process should be using it just to use it.

What we really need at this point, are better tools for using extra threads and better optimization. Most of the applications that I personally use don't benefit much from more processing power. I can give an entire core to my VM and the thing that really benefits from more processing power is compiling software, but I can do that while I'm asleep or out of the house, so having a faster computer isn't necessarily going to make it worth it for me personally.

We also need better security features to help guard against programming mistakes and to keep exploits as contained as possible.

Re:Waiting for chips?

[TechyImmigrant]

Depends on what your definition of "need" is. For example, I could say I need to run Minecraft with 220 mods, at 30 FPS, with hundreds of machine blocks. (with an i7-7700k I usually get around 11-12)

The straight up implementation of the Multi MMC Predictor algorithm over 1,000,000 symbols takes 20 minutes to run on my laptop. That's a problem when you want to test every device in a production line. I'll happily take a faster CPU.

Re:Waiting for chips?

[mikeabbott420]

we'll just keep "upgrading" your software until you do - and we won't stop then either

Re: Waiting for chips?

[Anonymous Coward]

You will! And when your faster chips come, they will be ready and waiting to slow tour computer down the pointless shit and give u a slower alternative to JavaScript

Re: Waiting for chips?

[Anonymous Coward]

Yesterday at work an application team bitched because I wouldn't give them a VM with 128 CPU.

Re:Waiting for chips?

[Anonymous Coward]

Who is Chris? Who are you? Why should we care?

Re:Waiting for chips?

[reanjr]

Unfortunately, software developers keep introducing endless layers of abstraction so that shit still isn't running nearly as fast as it should be.

Re:Waiting for chips?

[commodore64_love]

The 500 Plus in 1995 was nothing to brag about.... it was still using a 68000 processor when other Motorola machines like Macs were on 68060s (at ten times the clock rate). Now if you had said "1985" then it would be impressive (the Amiga's initial release date).

I ran a modern web browser on a PowerMac G3 (1999).... slow as snails. Ditto on a Pentium 4 at 3000 megahertz. SD video is okay, but HD video runs like molasses.

Re:Waiting for chips?

[Anonymous Coward]

I'm not Chris. Chris did post a comment this morning. Why are you shitting on The Original CDR instead?

Re:Waiting for chips?

[Anonymous Coward]

When your computer is fast enough to do everything that you need to get done in a reasonable amount of time, do you really need faster chips?

Wordperfect 5.1 created letters and resumes just fine 1989: why does one need WYSIWYG? Or on the fly spell checking? Or grammar checking? Isn't WP 5.1 all that one "needs"?

I mean, who need video on one's home computer? I didn't have that on my 1980s C64 or 1990s 386 and didn't feel I "needed" it (not knowing that such a thing was even possible at all, let alone several decades ago).

Why does one "need" high speed Internet? We did just fine 9600 bps modems, BBSes, and Fidonet when I was in high school. Who "needed" 1.5Mbps DSL (never mind FTTH)?

Are there diminishing returns in many cases? Sure. But just because your "needs" aren't onerous doesn't mean other people can't use those capabilities.

Serious why the fuck are you even on Slashdot if you don't think 'progress' in technology is at least useful (if not "needful").

Re:Waiting for chips?

[sosume]

In the eighties we needed only 640kb of RAM, in the nineties a 1 Gb hard drive was more than enough space, in the new millennium HD was all the resolution we needed, and now we don't need faster chips?

Re: Waiting for chips?

[Anonymous Coward]

It depends, man times it is much cheaper for a company to buy morse ram and faster cpus then to pay someone to optimize it. People want a cheap quick fix. Not a long wait and a huge price tag in the end. Hardware is cheap and software dev is expensive. But If we run out of mores law the scale will tips.

Re:Waiting for chips?

[Anonymous Coward]

I can always think of new things I want to get done with a computer. Then I need something faster.

Re:Waiting for chips?

[lgw]

You couldn't run a modern web browser on that, but that's because modern web browsers and web apps are just about the most bloated sacks of shit imaginable. 10 pounds of shit in a 5 pound sack with a tear in it.

But there's nothing inherently expensive in what a web browser actually accomplishes, other than playing compressed video. Flowing text to fit the screen in real time was impractical for 8-bit processors, but by the 16-but days it was fine. Javascript is horrifying, but there's nothing impossibly slow about parsing a page description / DOM. A good binary format designed for rapid parsing, gifs instead of jpgs, images sized for "back in the day", and a scripting language designed for performance.

Re:Waiting for chips?

[Aighearach]

That's the whole point of the story; with improved software architecture you might be using an algorithm that scales horizontally, in which case there would be no need at all for a faster CPU, just more CPUs. Or even, more subsystems; maybe doing too much of the work in a CPU is the problem? In a lot of tools that I use, the hard parts are done in an FPGAs and embedded microntrollers and the CPU is just managing the user interface and system buses.

Re:Waiting for chips?

[Aighearach]

And yet, it could run an old web browser that could easily display normal pages of data. It seems the only thing that it would actually choke on would be all the advertising and user tracking scripts. A few changes is CSS and things, but those have low overhead.

Re:Waiting for chips?

[Anonymous Coward]

You have to be a dipshit to think that your bullshit with Chris has gone unnoticed on Slashdot. Are you done being retarded?

Re:Waiting for chips?

[Anonymous Coward]

The return of the Transputer? At 4GHz.

Re:Waiting for chips?

[Dragonslicer]

That's the whole point of the story; with improved software architecture you might be using an algorithm that scales horizontally, in which case there would be no need at all for a faster CPU, just more CPUs.

That isn't a new computer architecture, it's the same kind of distributed computing that I learned ~20 years ago, and it wasn't all that new back then, either. Maybe some new programming language could make it easier to implement some distributed algorithms, but current languages have the capabilities already.

Re:Waiting for chips?

[Pfhorrest]

Macs never used '060s. The last straight-up Moto chip used in a Mac was the '040, then it switched to PowerPC (which was still partly Moto, but you know what I mean).

Reminds me of a computer class in high school around the time of that switch, and the introduction of the Pentium, when our teacher was saying that Macs used 68020, '030, '040, '050... while PCs used 286, 386, 486, 586... and I had to interrupt and correct him on two counts.

Re:Waiting for chips?

[AHuxley]

4K with full game support. Not at 50 fps and lower game settings. Want some new ray tracing support in that too? Thats a new CPU and GPU.

Re:Waiting for chips?

[HiThere]

Well, last week I left a job running overnight, and in the morning it still wasn't finished. It did eventually finish, so you can argue that I don't *need* a faster computer, but I'd sure like one.

Re:Waiting for chips?

[Darinbob]

However that modern web browser does a lot more work because it's doing a lot more unimportant stuff as well. Browsers do a ton now of stuff that they should not be doing - Javascript and stuff sucking doing so much work that I could feel my computer slowing down until I killed the browser. Do browsers really need to be doing all this extra stuff? The Amiga was perfectly fine for an early web browser.

Consider word processing. The modern Word does not feel faster than the word processing I did on the Amiga. In fact often Word seems slow despite all the massive computing power thrown at such a simple problem. The Amiga felt crisp and snappy, while Office apps today are sluggish. They're doing exactly the same job, except that the modern Word has all these extra features added that aren't necessarily useful. As computers get faster and faster over time, applications lagged behind and became slower.

That's part of the problem here - with all this computing power why don't we see anything good come from it in our applications? We only buy faster computers just to stay ahead of the application slowdown. Just look at word processors, every year they're slower and there's nothing new in them since the Amiga days except for spelling/grammar checking and rendering. The rendering is fast today and not a cause of slowdowns, instead it is the application portion of Word that is the bottleneck.

Re:Waiting for chips?

[Darinbob]

1995 was actually after they stopped building Amigas. The 500 Plus was in 1991, and more of a last gasp, while the original 500 was in 1987.

Re:Waiting for chips?

[Anonymous Coward]

That's why cloud computing exists you fucking idiot.

Re:Waiting for chips?

[Anonymous Coward]

In my new computer architecture, that I started working on 10 minutes ago, there is no HD video.

Give me one important use case for HD video...that everyone needs, not medical doctors working across the country, or pr0n fans.

Re:Waiting for chips?

[Anonymous Coward]

yes

Re: Waiting for chips?

[Anonymous Coward]

This is my favorite comment on here!

Re: Waiting for chips?

[Anonymous Coward]

Organic chemistry lectures

That was easy, why are you so bad at this?

Re: Waiting for chips?

[Anonymous Coward]

My favorite comment is the post that started the thread.
--
How to Pronounce The New Apple iPhone XR, XS & XS Max (September 2018)

Re:Waiting for chips?

[Anonymous Coward]

Here is the story of creimy the mountain and his royalties!

This story was inspired by cdreimer, the grand-parent poster. The story was written by a visionary on cdreimer birth date.

The story of creimy the mountain explained:
https://en.wikipedia.org/wiki/...

Creimy is a typical mountain who poses for postcards, living with his wife Ethel, a tree, between the cities of Rosamund and Gorman, California. The main features on his mountainous face are two large caves, resembling eyes, and a cliff for a jaw, which moves up and down when he talks, puffing up dust and boulders.
click above link to read more, he even destroyed Edwards Air Force Base just by passing by...

Listen to the audio version here:
https://www.youtube.com/watch?...

"Creimy The Mountain"

includes quotes from Pomp and Circumstance March No. 1 in D major (Edward Elgar), Johnny's Theme (Paul Anka), Off We Go Into The Wild Blue Yonder (Crawford), O Mein Papa (Paul Burkhard), Over The Rainbow (Harburg/Arlen), Star-Spangled Banner (Smith/Key), Suite: Judy Blue Eyes (Stephen Stills)

One, two, three

CREIMY the Mountain
CREIMY the Mountain
A regular picturesque
Postcardy mountain
Residing between lovely
Rosamond and Gorman
With his stunning wife ETHELL, A tree! A tree!

CREIMY was a mountain ETHELL was a tree Growing off of his shoulder

CREIMY was a mountain
(CREIMY was a mountain!)
ETHELL was a tree Growing off of his shoulder
(ETHELL was a tree growing off of his shoulder)
(hey, hey hey!)

Creimy had two big
Caves for eyes,
With a cliff for a jaw
That would go up 'n down,
And whenever it did,
He'd puff out some dust,
And hack up a boulder (HACK!) Hack up a boulder (HACK! HACK!)
Hack up a boulder (HACK! HACK! HACK!) Up a boulder

Now, one day, now I believe it was on a Tuesday, a man in a checkered double-knit suit drove up in a large El Dorado Cadillac, leased from BOB SPREEN

("Where the freeways meet in Downey!")

And he laid a HUGE, BULGING ENVELOPE right at the corner of CREIMY THE MOUNTAIN, that was right where his 'foot' was supposed to be.

Now, CREIMY THE MOUNTAIN, he couldn't believe it! All those postcards he'd posed for, for ALL OF THOSE YEARS, and finally, now, AT LAST, his Royalties!

Royalties! Royalties Royalties! Royalty check is in, honey!

Yes, CREIMY THE MOUNTAIN was RICH! Yes, and his eyeball-caves, they widened in amazement, and his jaw (which was a cliff), well it dropped thirty feet!

A bunch of dust puffed out! Rocks and boulders hacked up, (hack! hack!) crushing 'The LINCOLN'!

I gave him the money He acted real funny He hocked up a rock and It TOTALLED my car!

Oh, do you Know any trucks Might be bound for THE VALLEY?
I don't wanna stand here All night in this bar (Dear Lord)

I don't wanna stand here All night in this bar (No shit!)

I don't wanna stand here All night in this bar!

By two o'clock, when the bars are already closed down, CREIMY had broken 'THE BIG NEWS' to ETHELL. And with dust and boulders everywhere, CREIMY, choked with excitement, announced

"ETHELL, we're going on a VACATION!"

Yes, and they WERE going on a vacation! (Oh, and ETHELL, ETHELL, ETHELL, like every little woman, she of course was very excited! She creaked a little bit, and some old birds flew off of her.) CREIMY told ETHELL they were going to Yes! They were going to NEW YORK!

"ETHELL, we're going to New York!"

But first they were gonna stop in LAS VEGAS

It's off to LAS VEGAS to check out the lounges Pull a few handles,
And drink a few beers, (Oh, ETHELL!)

ETHELL, my darling, you know that I love you!
I'm glad we could have a Vacation this year! (Oh, NEET-O!)

Glad we could have a Vacation this year!

They left that night, crunchin' across the Mojave De

Re:Waiting for chips?

[Anonymous Coward]

Here is what is much worse than laziness alone; some people are lazy and stupid

For example, take creimer and his stupid and dead youtube channel that was supposed to be his long tail revenue stream for his retirement.

He has been told several times that he should finish his certifications instead but he is too lazy to do that and he finds it easier to post stupid stuff on YouTube.

Since nobody watches his stupid stuff. He decided to publish a border line kid video that he filmed himself. Then he posted in various forums, faking outrage to bring views to his channel arguing with himself with different sock puppets names.

Here is basically what it looked like:
creimer wrote:
https://slashdot.org/comments....

Have you seen creimer's children band video [youtu.be]? Holy shit! That video got hundreds of view [twitter.com] with 95% coming from outside of the United States and the top three nations are well known for sex tourism. It doesn't surprise me that Slashdot has so many pedobears.

and:
https://slashdot.org/comments....

No. Thanks to YOU for calling me a pedophile. It has become my best performing video in the first 24 hours to date. All those views came from OUTSIDE the United States. Ukraine being 11% of the total.

and:
https://slashdot.org/comments....

Thanks to your Pedobear buddies, I got 25 hours of watch time in three days and coming in second to my Slashdot video with 30 hours of watch time in six months. Keep up the good work!

So basically creimer, you are bragging about providing video material to pedophiles and sex tourists and you do not see any problems with it as long as it brings views to your youtube channel.

Poor Chris, sad, very sad...

How long will it be before you do the right thing and take that video off line?

update: see creimer's replies here:
https://tech.slashdot.org/comm...

https://news.slashdot.org/comm...

https://slashdot.org/comments....

https://tech.slashdot.org/comm...

Re:Waiting for chips?

[guacamole]

Your comment is right on the money. I recall the time when the rapid succession of ever bigger and more complicated operating systems demanded that we all upgrade hardware, because hardware that did well under Windows 3.1 would not do well running Windows 95 or 98. The hardware that run Windows 95 or 98 well, would not run Windows 2000 or XP. The XP hardware was not sufficiently fast for Windows Vista or 7.

The reason for that was that the older OSes like 95 were junk. They lacked true multi-user multitasking features, they sucked at networking and security. But the subsequent OSes fixed that.

After Windows 7, the Microsoft operating systems (as well as others) have reached a certain degree of maturity. These were now OSes with true multitasking, multi-user, networking and security features. As a result, the trend after Windows Vista was that the subsequent versions would actually run better and better on the same hardware. A computer that comfortably run Windows Vista, can still run Windows 10 today. I have tested this hypothesis on a couple of Core 2 desktops from something like 2008-9.

Re: Waiting for chips?

[Anonymous Coward]

Yes, you're right of course.

Which is why I got a chem eng degree with no personal computers in existence, let alone HD video.

In short, gimmick.

Re:Waiting for chips?

[TechyImmigrant]

Magically mapping naive algorithms to efficient algorithms would be a start. I'll be working on making it faster the hard way - probably parallelizing it, possibly making a more efficient algorithm.

FPGAs are handy when you are running locally - especially if you happen to be a hardware engineer. Not so much when you're expecting it to run on arbitrary machines.

Re:Waiting for chips?

[Aighearach]

Why would running on arbitrary machines even be interesting?

Yeah, if that is what you want, by definition you're only working within the lowest common denominator and you don't need to worry about new architecture possibilities; that becomes relevant 20 years after most of the market switched.

I'd be much more interested in automatically mapping naive algorithms to efficient algorithms on a wide variety of new systems built according to one of the new architectures discussed! :)

Re:Waiting for chips?

[Aighearach]

You're saying, it isn't a new architecture because the engineering principles aren't new.

I would suggest you reconsider the difference between architecture and engineering.

Re:Waiting for chips?

[TechyImmigrant]

Why would running on arbitrary machines even be interesting?

Because I don't expect every machine to have an FPGA rig running next to it.

Re:Waiting for chips?

[Anonymous Coward]

One gigabit hard drive? I don't think hard drive capacities were ever measured in bits.

Re: Waiting for chips?

[Hognoxious]

Meh. Polystyrene balls and toothpicks FTW.

Re:Waiting for chips?

[Hognoxious]

while PCs used 286, 386, 486, 586

It was called the Pentium instead because if you added 100 to 486 you got 585.999983605.

TY,IHAW.

Re: Waiting for chips?

[Anonymous Coward]

You were lucky Windows didn't restart on you while your job was running.

Re: Waiting for chips?

[Anonymous Coward]

WTF is your problem? It's like there is a trend to depower us by pushing all meaningful computer work out to other people's computers. Now I think about itz that's the underlying motivation of Windows 10 with its forced restarts: have a conpute job work doing? Farm it out to the cloud! Sheesh!!

Re:Waiting for chips?

[Agripa]

When your computer is fast enough to do everything that you need to get done in a reasonable amount of time, do you really need faster chips?

Yes, we need faster chips so we can produce slower software.

Re:Waiting for chips?

[Anonymous Coward]

A major reason why users do not perceive performance advantages, is, that they now use a web browser almost all the time, and most people do so without adblockers, and without NoScript (in Firefox), or some other ad/scriptblocker elsewhere, such as uBlock Origin, or uMatrix (to each their own).

These tools are some of the most basic ways of optimising resource usage in a browser, and go a long way in making websites and browsers more reponsive, thereby improving speed and user experience.

Alas, most people don't have that, and advertisers are reaping great benefits thereof.

On top of that, there's the transformation of simple web pages into resource-heavy webapps. There used to be a time, when I could still use Firefox 1.0 on an older computer without having to worry too much about not getting a connection to where needed, since many sites were carefully designed to match the relatively basic abilities of their target audience. Anything fancier used Flash. But that was when desktops and notebooks were not particularly powerful as a class.

Now, though, a newer browser is a must both due to security implications, and because of video providers using newer codecs in order to increase video resolution size (4K and up), and to simultaneously seek to have a lesser load on the network in the face of more and more users gradually getting to see all that fancy 4K video on their 4K screens. Soon-to-be 8K. While most simply contend with 1080p as some sort of a standard.

Security is also a thing, and a faster rig or farm is able to break ciphers faster, too. A major gaming rig with several cores has the power comparable to any supercomputer of the days of yore, but is not necessarily faster in terms of user experience, because the software is awful (Windows 10), or a badly-coded website with terrible fonts and CSS, or a site that mines coins without the user noticing, but then complaining, that 'their computer is slow.'

Or simply lots of sites without being active on several tabs at any one time, without the browser having adblockers on. Firefox mostly has a remedy for that, and I think, Google Chrome -- despite its awful recent flaws -- is coming up (or has come up) with a suspend feature for inactive tabs.

Yes, even M0AR Languages

[Anonymous Coward]

We've only had three new ones come out this week. We need M0AR! M0AR languages!! M0AR syntaxes!!

M0AR of all the things!

In fact, it should be a requirement for all CS majors to develop their own language before graduations, so everyone can be *THE* subject matter expert in a language. That would be awesome. Everyone would be able to charge $500/hr for being the ONLY expert in their language.

What could be wrong with this??

Re:Yes, even M0AR Languages

[Anonymous Coward]

OK... the message is a bit strident but the AC ain't wrong! Definitely needs modded up to at least a +5.
--
Steve (AC because I haven't bothered to register in all these years)

Re:Yes, even M0AR Languages

[Anonymous Coward]

“Revolutionary new hardware architectures and new software languages, tailored to dealing with specific kinds of computing problems, are just waiting to be developed,” he said.

DSLs and domain optimized custom architectures is what the article seems to be saying that Patterson is advocating.

Re: Yes, even M0AR Languages

[Anonymous Coward]

Pattersons' really advocating for an alternate reality. Easy to ignore people like that. They are almost always found in academia, which lets face it is an alternate reality in itself.

Re:Yes, even M0AR Languages

[mccalli]

To be honest, it used to be. What's now called domain-specific languages, we used to call Lex and YACC exercises. You had to learn various grammars etc. and be capable of developing your own. This would be 1990-92, for all I know it still is a requirement, though I would imagine the tooling has changed.

The belief in syntax as immutable is wrong - it's a tool like any other, change it if it holds you back. I'm thinking now about the continued wedding to things like C etc. - they have their place, but they're not the way forward anymore.

Starting in 2005

[Jogar the Barbarian]

A SPECint graph shared on Quora shows this slowdown starting back in 2005.

https://qph.fs.quoracdn.net/ma...

Re:Starting in 2005

[egladil]

That graph seems to confirm Moore's law is still holding.

"Moore's law is the observation that the number of transistors in a dense integrated circuit doubles about every two years." - Moore's law

Re:Starting in 2005

[TechyImmigrant]

That graph seems to confirm Moore's law is still holding.

Yep. It leaves off the multi-core performance which should follow the transistor count growth.

Re:Starting in 2005

[pz]

People confuse Moore's law with performance. Moore observed that the total number of transistors on a chip was doubling every 18 months. For a long time, that meant that the clock frequency was also doubling.

Then, a nasty habit of physics to smack us in the phase --- err, face --- came along in the form of speed of light limitations. Given the size of contemporary chips, it just is not (and is unlikely to ever be, if what we know about fundamental physics is correct) possible to communicate from one side of a 1 cm die to the other much faster than in the range of a handful of gigahertz clock speeds, give-or-take. Even with photons going in straight lines in perfect vacuum (none of which happens on a chip) the best you could hope for would be a 30 GHz clock rate, a paltry ten times faster than today's CPUs.

One obvious solution is to make circuits that are smaller, and thus we started to get more CPUs on a single die. Still, those CPUs need to synchronize with each other, the cache system, etc., so there remain chip-spanning communications constraints.

The limits on the size of transistors, and thus perhaps on the total number on a chip, are looming but haven't arrived yet. The limits of raw clock speed most definitely have. It is safe to say that our chips will continue to get faster for a while, but the heady days of generation-to-generation massive improvements in single-thread CPU performance are over.

Re:Starting in 2005

[commodore64_love]

From wikipedia: Intel stated in 2015 that the pace of advancement has slowed, starting at the 22 nm feature width around 2012, and continuing at 14 nm. Brian Krzanich, the former CEO of Intel, announced, "Our cadence today is closer to two and a half years than two." Intel is expected to reach the 10 nm node in 2018, a three-year cadence.

So Moore's Law is slowing from 2 to 3 years.

Re:Starting in 2005

[commodore64_love]

In Star Trek TNG they used warp fields to enable data transfers faster than light speed. (Yes I know warping & FTL is just fiction.)

Re:Starting in 2005

[Anonymous Coward]

It also ignores massive improvements in data storage and retrieval speeds, RAM speeds, bus speeds, etc.

Re:Starting in 2005

[DRJlaw]

From wikipedia: Intel stated in 2015 that the pace of advancement has slowed, starting at the 22 nm feature width around 2012, and continuing at 14 nm. Brian Krzanich, the former CEO of Intel, announced, "Our cadence today is closer to two and a half years than two." Intel is expected to reach the 10 nm node in 2018, a three-year cadence.

So Moore's Law is slowing from 2 to 3 years.

Which slipped to 4Q2019, with little prospects of an (Intel-scale) 7 nm process following on any reasonable timescale.

3 years my hiney... the hockey stick of development time versus feature scale went to 4 years and it's not stopping there...

Re:Starting in 2005

[Anonymous Coward]

Here's a slightly more updated version, 42 years of data:

https://www.karlrupp.net/wp-co...

From here:

https://www.karlrupp.net/2018/...

Re:Starting in 2005

[Anonymous Coward]

Next big step may be packing it all into a cube and getting everything ever closer together. Cooling this enough may however be forever impracticable.
Eventually the only way to scale would be horizontally, like what's happening with GPUs.
Some folks believe the only way to get past the cooling problem is reversible computing... but from everything I've read about reversible computing, it seems unlikely to happen, because it's exponentially more difficult to design for than classical computing.

Re:Starting in 2005

[Darinbob]

There are more transistors being used, but not within the same space. So while the transistor count has been going up in microprocessors that does not mean that transistor density has been going up.

Re:Starting in 2005

[Anonymous Coward]

Performance has stayed the same for the last 15 years thanks to bloating software.

Re:Starting in 2005

[Anonymous Coward]

Then, a nasty habit of physics to smack us in the phase --- err, face --- came along in the form of speed of light limitations. Given the size of contemporary chips, it just is not (and is unlikely to ever be, if what we know about fundamental physics is correct) possible to communicate from one side of a 1 cm die to the other much faster than in the range of a handful of gigahertz clock speeds, give-or-take. Even with photons going in straight lines in perfect vacuum (none of which happens on a chip) the best you could hope for would be a 30 GHz clock rate, a paltry ten times faster than today's CPUs.

Whoa check your math... One clock cycle does not mean a signal travels across the die, it means to the next gate usually. The number of cycles from input to output depends on pipeline depth. Per-cycle a signal might need to travel 10-100nm depending on gate size, meaning a possible clock rate in the range of 10^17 Hz. Of course, there are other limiting physical charchteristics but c - the speed of light isn't it.

Re:Starting in 2005

[Anonymous Coward]

I'll take 10 times faster, thanks. It's a lot better than 2% faster. Now, when can I pick up my 30GHz chip?

Re:Starting in 2005

[Anonymous Coward]

Sometimes it took days/weeks sometimes it was real time video calls

Re:Starting in 2005

[Anonymous Coward]

> not ... possible to communicate from one side of a 1 cm die to the other much faster than in the range of a handful of gigahertz clock speeds,

You're assuming that communicating from one side of the chip to the other limits clock speeds. It doesn't. High performance chips have been store-and-forward networks for years. Yes, it takes multiple clocks to get from one side to the other.

Re:Starting in 2005

[Bengie]

You do point out the issue of current systems and there's no hardware silver-bullet that wouldn't changes to algorithms and datastructures of existing currency logic. But cache-coherency is not a requirement, but does have certain trade-offs when it comes to concurrency like latency, and execution units within a CPU do not require being in sync. There are async CPU designs that can clock very high, but they're much more complex, few people are able to designing them, almost no tooling to design them, and have thus far been more difficult than just throwing more transistors at the problem. I'm not sure what performance trade-offs there would be.

Re:Starting in 2005

[Agripa]

A SPECint graph shared on Quora shows this slowdown starting back in 2005.

https://qph.fs.quoracdn.net/ma...

Moore's law is about cost per transistor (integration) and that graph shows it continuing up to the last data.

Re:Starting in 2005

[Agripa]

There are more transistors being used, but not within the same space. So while the transistor count has been going up in microprocessors that does not mean that transistor density has been going up.

Moore's Law does not make any distinction between transistor density, chip area, or packaging. The only thing which matters is cost per transistor which can be lowered through any of these things. This can even come at a cost in transistor performance which has happened several times.

Moore's Law over?

[110010001000]

Moore's Law is over? I've been saying that for 8 years. Of course whenever I say it here on Slashdot I get assailed by people who can't accept the truth.

Re:Moore's Law over?

[Anonymous Coward]

The truth is that Moore’s law does not talk about performance but about chip density in any integrated circuit and then only every 2 years, not 18 months. Most people think that chip density equals performance and in some cases that’s true, but these days we’re gaining both performance and power efficiencies by integrating more and more things on-die.

We have entire computers with all their busses (USB, PCI, I2C, Ethernet, BT, WiFi) on-chip and all you have to do is attach connectors and antennae.

Re:Moore's Law over?

[110010001000]

Yes we get it. There is always one pedant who defines "Moore's Law". What Moore's Law really means in this context is that processors aren't getting faster. The computer you have today is only marginally faster than the one you had last year and the one before that.

Re:Moore's Law over?

[cfalcon]

Because Moore's law is more about transistor density. It's an easy nit to pick.

It's still a big deal that we aren't getting any easy gains on single core speed, or, factoring in all their new fancy branch predictions, single thread performance. But newer CPUs are fitting more cores in, newer GPUs are wildly more effective (at a fundamentally parallel task). These are the arguments for Moore's law actually being still online.

Anyone who was around for the late 90s or before knows that computers simply aren't doing what they did before- completely obliterating previous generations of computing. A machine from 2008 can run most current games, and those it can't inherit their restrictions artificially (a motherboard that won't take a new enough GPU, for instance). It can certainly run the latest version of pretty much any OS, and many productivity programs. If you do that comparison from 1999 to 1989, it's a joke- a Pentium III at nearly a gigahertz compared to a 486 at like 50 or 66 megahertz. Look back again at 1979, and you are comparing to an 8086 or something.

Re:Moore's Law over?

[110010001000]

No. Moore's Law is dead. Some pedant always crawls out of the woodwork and starts talking about "transistor density". Even GPUs are hitting a dead end.

Re:Moore's Law over?

[commodore64_love]

As I posted above Moore's Law says "transistors will double every 2 years". That held true until 2015, when it slowed to 2.5 years (not a huge difference).

Re:Moore's Law over?

[ArchieBunker]

Gordon Moore's paper seems pretty clear on component count. https://drive.google.com/file/...

Re:Moore's Law over?

[Anonymous Coward]

No. Moore's Law is dead. Some pedant always crawls out of the woodwork and starts talking about "transistor density". Even GPUs are hitting a dead end.

Here's a small hint to help you through life: When you are provably incorrect, it's not smart to double down.

https://en.wikipedia.org/wiki/...

Re:Moore's Law over?

[thegarbz]

I've been saying that for 8 years. Of course whenever I say it here on Slashdot I get assailed by people who can't accept the truth.

Only because you a) don't understand Moore's law, or b) can't count to 7000000. Moore's law is alive and well and only slightly behind the trend line in the past two years. Even Intel is doubling the transistor count and changing gate size every 2.5 years now instead of every 2 years as Moore's law predicted.

8 years ago? Don't tell me you, a person who's nerdy enough to read news for nerds doesn't understand that the only part of Moore's law is counting transistors. I mean it's not like you confused it with single core performance right? RIGHT?

Re:Moore's Law over?

[thegarbz]

Some pedant always crawls out of the woodwork and starts talking about "transistor density".

You mean pedants like Gordon Moore who invented the law carrying his namesake? But I mean there's no need to take anyone's word for it. errr. Except this guy's: http://www.lithoguru.com/scien... he's kind of a guru when it comes to his own law.

Re:Moore's Law over?

[Anonymous Coward]

What Moore's Law really means in this context is that processors aren't getting faster.

You are a fucking idiot and you should feel bad.

Moore's Law has never, ever been about speed. It has always been about transistor density.

Re:Moore's Law over?

[Anonymous Coward]

no Moore's Law said transistors were doubling every 18 months. They fudged it to 24 months later when the rate started to slow. Yes it's a great time to go back to the 70s and using better c compilers. Unless Quantum Computing actually works.

Re:Moore's Law over?

[complete loony]

I recently upgraded to an i7, from a CPU that was first released about 10 years prior. According to online benchmarks, my new CPU is only 5x faster at single threaded tasks. There are way more transistors in my new CPU that do more work in parallel, even within a single core. Instruction decoding, instruction decode caching, scheduling, speculating, .... That theoretical 5x speed up has more to do with throwing more transistors at the problem, not because the transistors themselves are much faster.

Re:Moore's Law over?

[tomxor]

...the only part of Moore's law is counting transistors.

Moores law was as observation stated in the 60s... what was implicitly meant is dennard scaling, which was not explicitly defined until the 70s. Doubling _was_ a side effect of halfing the transistor size and being able to fit double the transistors on the same die, but you get two things from this:

1. More transistor logic possibilties.

2. faster clock

Number 2 is obviously what everyone used to fixate on because it's an easy to quantify, single dimmensional number that you can slap on the front of boxes and don't have to explain to anyone.

I mean it's not like you confused it with single core performance right? RIGHT?

It pretty much used to mean that, and largely still does when interpretted as intended. We are reduced to improving single core speed through moving logic around only - the only architectural agnostic things to quantify here are tricks of computational reduction and speculation, and not everything _can_ be computationally reduced - many operations are just too fundamental that out of a larger context they are always going to be limmited to propagation delay which has stayed still since 2006.

Re:Moore's Law over?

[NikeHerc]

What Moore's Law really means in this context is that processors aren't getting faster.

From https://en.wikipedia.org/wiki/Moore's_law: "Moore's law is the observation that the number of transistors in a dense integrated circuit doubles about every two years." Moore's law is *not* about CPU speed. From the same link: "In general, it is not logically sound to extrapolate from the historical growth rate into the indefinite future."

If you know anything about creating circuitry from silicon and its compounds, the statement on extrapolation won't be shocking news.

Re: Moore's Law over?

[Anonymous Coward]

But that's not the common understanding of it. The common understanding, the one presented over and over in every magazine and paper since the 90s, the one which has been true up to this time... That law is dead

Literally nobody gives a shit about the one you're talking about. It doesn't matter if you're "technically correct" because you're wrong

Re: Moore's Law over?

[Anonymous Coward]

I think you hit the nail on the head... "nobody gives a shit"

And that's the problem!

Moore's law is actually about economy, not performance or technical acumen.

Re:Moore's Law over?

[thegarbz]

It pretty much used to mean that, and largely still does when interpretted as intended.

Not even remotely. In fact Moore was quite explicit in what he defined as a component in his observation and prediction. "a component being a
transistor, resistor, diode or capacitor, in an integrated structure"

Just because work is now split up into multiple cores doesn't make the single die any less of an integrated structure, and doesn't change the purpose of the law which was to count functions on an IC.

Moore's law doesn't even take into account the physical size of the IC. So even if transistors stayed the same, simply throwing double the cores at the problem and making the chip twice as large still is very much Moore's original observation which had everything to do with manufacturing cost when he defined his law.

You can make up whatever you want. It won't make it any less wrong when discussing what someone explicitly said in a paper.

Re:Moore's Law over?

[tomxor]

Moore's law doesn't even take into account the physical size of the IC. So even if transistors stayed the same, simply throwing double the cores at the problem and making the chip twice as large still is very much Moore's original observation which had everything to do with manufacturing cost when he defined his law.

You are completely ignoring the context it was observed in... in an era where shrinking process size was the driving force in doubling transistor count - a phenomenon that improved a processor threefold: increases transistor count, switching speed, reduces local propagation delay, increases power efficiency and most importantly had a reasonably sustainable future to _continue_ improving until it hit the fundamental limitations of the materials used.

Now look at the remaining ways transistor doubling happens without shrinking the process size: increasing die area? that only increases transistor count, it does nothing for switching speed, propagation delay, power efficiency and introduces logistic problems, thermal problems and most importantly has little future (how sustainably can you keep increasing die area before we go back to room sized computers - except with out current transistor density those room sized computers would be consuming trillions more watts than their predecessors).

In short: your arguments seems to be that moore's observation is alive because transistor count still increasing in spite of it happening in an entirely different way at an slower rate, with almost none of the benefits that the original phenomenon endowed on processors with no sustainable way of continuing to increase transistor count in the foreseeable future.

Moore's law is informal observation, not a well defined law, if you interpret it as a pedant you will miss the point - look at it from the authors perspective.

And?

[cascadingstylesheet]

And? What if we don't need it to keep getting endless faster?

Re:And?

[110010001000]

Many things people hope to come true in the future are predicated that processor power increases. If it doesn't, we have hit a wall technically. Much of the progress in the last 50 years is based on digital computing.

Re:And?

[Anonymous Coward]

There are always applicaitions for more compute power. Or the same compute power with less energy consumption, which is roughly equivalent.

Re:And?

[gweihir]

It does not really matter, because we will not get it going much faster than today anyways. There is no "new architecture" or "new language" that will change that. Massive parallel systems failed last century and did so several times. Vector architectures have just hit the same brick wall as conventional ones. There really is nothing else.

Re:And?

[gweihir]

We have hit that wall. This technology is mature and everything it can do well, it can do now at close to maximum-possible speeds. Sure, software sucks today and coders are mostly incompetent and there is some speed increase to be expected from that angle, but that is it. That there was an area of seemingly exponential growth does in no way imply it will continue without limits. And it does not.

Re:And?

[110010001000]

Correct. We have hit that wall. And that means a lot of things aren't going to come true that people were depending on. People were spoiled by digital computing and think that progress is inevitable. My point is that is isn't.

Re:And?

[Anonymous Coward]

Yes, and processors could also get more secure and more accurate. Considering how many processes are now connected, security features would be a good direction to be focusing additional attention rather than on getting faster. Sure, there's always going to be a need for more powerful computers, but for the most part, we have computers that are fast enough, what we need are computers that are more reliable and more secure.

Re:And?

[Anonymous Coward]

Quantum?

Re:And?

[gweihir]

I completely agree to that.

Turns out that in this the past is not a reliable predictor of the future, as is true in any other area.

Re:And?

[gweihir]

Magic?

No. Not going to materialize and even if it did, it would not accelerate most tasks, just a small set of very specific ones.

Re:And?

[avandesande]

Actually I would disagree with you the number of applications waiting for more computing power has diminished over time. When is the last time gaming was held up by processing? Going to 4k gaming is an exercise in diminishing returns.

Re:And?

[Roger W Moore]

We have hit that wall.

Not really. We have come to an obstacle that requires a change in tactic. Processing power is still increasing at Moore's law but only for multi-core applications. Once we adapt to the new paradigm where to double your performance you need to double the number of cores, things will pick up again. However, this is a really hard change to make and it is going to take some time to adapt.

Re:And?

[110010001000]

No really. We have. Processing power is not increasing.

Re:And?

[Anonymous Coward]

Wot? Massive parallel systems have failed? What are GPUs then?

Re:And?

[eth1]

When is the last time gaming was held up by processing?

Factorio? Kerbal Space Program? Dwarf Fortress? Any game that does heavy simulation?

Re:And?

[David_Hart]

Magic?

No. Not going to materialize and even if it did, it would not accelerate most tasks, just a small set of very specific ones.

But, if it works, there are tasks such as building predictive trees for applications that could speed up processing. For example, a GPU is is a processor dedicated to the very specific task of graphics processing (though we have found other uses, such as bitcoin mining). It's quite possible that we will find specific tasks that a quantum processor can handle much faster than a CPU. Offloading those tasks would provide a performance gain.

There is also the likelihood that there are other processes that can be offloaded as well that we just haven't thought of.

Re:And?

[Anonymous Coward]

The thing where processing power is most important (considering future inventions) is AI (and its usage in robotics). And for that Google has made TPUs that are faster that CPUs for AI calculations. So hardware is still improving where it matters the most.

Re:And?

[avandesande]

I don't play any of those but looks like they will easily run on my 9 year old i7 950

Re:And?

[Anonymous Coward]

Spoken like someone who hasn't got the slightest clue. Naivete is a good trait in marks, but not for the average adult, much less one on a tech-oriented website.

It's not a good look.

Re:And?

[gweihir]

Well, we should cross that bridge when we get to it. That will very likely not happen. So far QC has scaled extremely badly over the decades. A sub-linear scaling seems to be what is going on. Even if that scaling continues (unlikely) and does not hit a wall, classical computers will stay faster for many decades.

Also, your "predictive trees" are nonsense, at least as a QC application. Stop believing the hype.

Re:And?

[gweihir]

There is no "new paradigm" that could do what you predict. There are hard, established theoretical results that say that many important algorithms cannot benefit from more cores. Does nobody know the basics anymore?

Re:And?

[Anonymous Coward]

Woh, for realsies? I'd better make sure to let my friend know he just wasted his money buying his new Threadripper 2 2990WX. I'd better let him know it can't really compile the Linux kernel in 30 seconds. Processing power is not increasing. It's all just an illusion apparently.

Re:And?

[Anonymous Coward]

When is the last time gaming was held up by processing?

Fuck me. Modded to 3 by the circle jerk.
Heard of VR?
Let's see how your 9 year old computer goes rendering the latest games in stereoscopic ultra detail at 120hz.

Re: And?

[Anonymous Coward]

"I've never done the thing you said, and have no experience with it, but I'm going to claim I'm right anyway"

Re:And?

[Chelmet]

Don't bet on it.

Factorio, as the game from the above list with which I am most familiar, is a beast for performance. Your CPU will manage a small base without issue, and so meets the minimum specs, but will struggle massively once you increase the size and complexity of your base.

Factorio has a base clock of 60 updates per second (UPS). Frames per second (FPS) are limited to UPS, as there is no point displaying two consecutive, identical frames. So you start the game at 60 UPS, which means that your CPU has 16.6666 milliseconds to process each 'tick', and your CPU blazes through it it only 2 or 3 milliseconds. Once your base gets more complex, and there are more entities to track, that tick gets longer and longer, and once it passes 16.6666, you drop below 60 UPS. Large bases can fall to 10 UPS, even on monster PCs. I have an i7 6700 clocked at 4.6GHz, and it doesn't take long for me to drop below 60 UPS. Once you're in the 20 UPS range the game is really unplayable.

With Factorio it's important that your CPU is beefy, but apparently it's your RAM latency that can really make the difference due to the fact that the whole world is recalculated every tick.

While it's easy to say that Factorio will run on your 9 year old i7 950, that's if you only scratch the surface of the game. Performance of Factorio is most definitely limited by our current architecture.

Re:And?

[WorBlux]

How well is it spread out over threads?

Bring back 'capability machines'

[david.emery]

I worked on the BiiN project. https://en.wikipedia.org/wiki/... A 'capability' was a specific -hardware protected- feature that was set up to be unforgeable and contain access rights. This computer architecture approach date back to the Burroughs 6500 https://en.wikipedia.org/wiki/... and even back to some aspects of MULTICS.

They're definitely not von Neumann architectures, since a capability pointing to executable code is a very different thing than a capability pointing to data. In many respects, these would be "direct execution engines" for object-oriented languages (even C++, with some restrictions on that language's definition).

A huge part of this is getting over the illusion that you have any clue about the (set of) instructions generated by your compiler. If you're working on a PDP-8 or even PDP-11, C might well be close to 'assembly language'. But with the much more complex instruction sets and compiler optimizations to support those instruction sets, most languages are far removed from any knowledge of what the underlying hardware executes.

Re:Bring back 'capability machines'

[TechyImmigrant]

I have a few wafers of the 432 in my desk draw at work.

Re:Bring back 'capability machines'

[WorBlux]

Are you familiar with the proposed Mill architecture? Thier work with what they call turfs and portals sound very similar. It allows secure calls accross protection boundries, hardware managed data stacks, unforgeble process ID's, and byte-level permission granularity. It's definately not a RISC machine, but it's not a C machine either with hardware features that treat pointers as type of thier own which contain hardware managed meta-data bits usefull to accelerate garbage collection.

Re:Bring back 'capability machines'

[Anonymous Coward]

A few years ago I had some code that I thought I could optimize by rewriting a critical routine in assembly language. Just reading the processor manual was daunting with all the "gotchas" and side effects. My project turned out only very, very marginally better, almost in the noise. However I was left with an unmaintainable routine, understandable only by me. It just wasn't worth the extra effort.

Re:Bring back 'capability machines'

[Anonymous Coward]

Why? How exactly it solves anything? It failed once, what changed?

"A huge part of this is getting over the illusion that you have any clue about the (set of) instructions generated by your compiler" - most people don't have such illusion because they just were not interested in this part of the system. Those who were interested have fairly good idea what instructions are generated by the compiler. There are not that many ways to perform a given task using given instruction set, good compiler output is fairly predictable.

Also, this "huge part" seems to have absolutely no practical value. You got over the illusion that you understand how compiler works, good for you. It doesn't look like anyone else cares though. I for one wouldn't pay for it.

Re:Bring back 'capability machines'

[Anonymous Coward]

Compilers are good. People who write them usually read the processor manuals and take "gotchas" into account. Just rewriting the same algorithm in assembly doesn't make it faster by itself. If you look at compiler's result and can't see anything you could write better, there is no reason to mess with it.

Optical Buses

[Anonymous Coward]

If Intel wasn't so bogged down in their own ME bugs, maybe they could focus a bit more on optical buses.

That is really nonsense

[gweihir]

Various alternate architectures have been tried out over the decades. A lot of other programming models have been tried out as well. They all basically failed or live on only in niches because people could not hack coding for them.

Performance increases for most tasks are over. Deal with it and stop proposing silver bullets. It only makes you look stupid.

Re:That is really nonsense

[Anonymous Coward]

NVidia seems to differ. But there is the issue of legacy codes and the investments done for them, so some other people (EU) are designing to do something else with their double precision accelerators. I thin I remember Patterson arguing for DSLs earlier already. Maybe he considers certain problems or cores of them to be important and common enough to warrant custom silicon as well. The fabless model and FPGAs has made it a more attainable idea anyway, and issue of dark silicon is still here.

Exponential growth always hits an inflection point

[bkmoore]

Moore's law predicted early exponential growth in semi-conductors, but as in all fields it eventually hits an inflection point and becomes asymptotic, infinite transistor density will never happen.

"Waaah

[Anonymous Coward]

we can't make bloated software anymore. Uncle Moore stopped giving us ponies & candy."

Idiot. We have enough stupid languages. RISC sucks

[Seven Spirals]

As an SGI collector and fan of Unix hardware it pains me to say this, but: get real RISC is shit and so are it's engineers. This guy didn't get enough of being completely wrong in the 1990's he's gotta pile some more bullshit on top. First off, look around you, see any RISC processors that are worth a shit? I'm sure many will say ARM because they don't realize that the compute performance of an ARM chip is utter shit when seen in the light of what CISC has done. Yes, Intel and others have done silly-shit with execution pipelines and other now-dangerous-tricks. However, that still doesn't detract from the big flaw in RISC - the ISA. RISC was supposed to be just fine because everyone would just write everything in C and never get horrified at how idiotic the ISA was underneath. Compilers don't tend to use as many tricks as ASM coders do/can because any tricks they use have to be absolutely rigidly repeatable. A human ASM coder knows when he can use certain techniques and when they are better avoided. So, compilers did get better, and they sorta kinda partially made up for the shitty internal design of their RISC chips. Trouble was, RISC solved a problem that was temporary - lack of space on the silicon. The advances in lithography since the 1990's has made RISC seem pretty damn ridiculous. In fact, chip makers had so much space from the smaller litho, they didn't even know what to do with it! Heaven forbid they hire more engineers or do anything interesting - so they just stamped out more cores on the same silicon. These days, we are drowning in so much geography on the chips that the problems RISC aimed to solve are totally irrelevant. Anyone who cut their teeth making RISC chips is already extremely suspect to me. Though I can see why they'd call for new architectures, they are used to ones that suck balls.

A Question

[Anonymous Coward]

I have the start for a new language compiler concept. It is: designed to be secure; hugely scaleable; designed to take advantage of genetic algorithms; resilient; able to automatically port compiled code to new CPUs; hot updatable; able to use a variety of programming languages (though not existing ones); able to run a single problem across multiple CPUs on multiple machines automatically; etc.

The question is: how do I develop this while keeping the mortgage paid and making a profit?

Note: in theory, I could hand it off to someone else but, as the concept is mine, it would kill me if they mucked it up.

Re: A Question

[TimMD909]

Making mortgage payments and profits wasn't something Linus was worried about, and things turned out pretty well for him until recently. 20+ years is a good run. If it's as amazing an idea as you say, I don't really see any obstacles other than the ones you place in your own way.

Re:A Question

[Anonymous Coward]

Keep the mortgage paid and put all your free time into doing it. Whatever you do, don't NOT do it.

If you're really confident in your ability to execute, downsize the house so you can work less to keep it up, and put even more time into the compiler.

Don't worry about the profit until you see that it works.

Re: A Question

[Anonymous Coward]

Making mortgage payments and profits wasn't something Linus was worried about

That's because he was at university and didn't have any responsibilities in life other than getting his degree. I'm 49 and have all of the commitments that suggests. I don't mind some pain or drawing-in my belt but it took me 7 years to save for the deposit on my house...

On the plus side, it looks like Erlang will be useful in doing PoC work so I've started getting into it.

Re:A Question

[Anonymous Coward]

If you're really confident in your ability to execute, downsize the house so you can work less to keep it up, and put even more time into the compiler.

Don't worry about the profit until you see that it works.

There's no way I'm selling the house just for a compiler that may may never give any return. Even if it works perfectly and takes off, it could leave me with nothing if big firms copy its ideas and embrace-extend or whatever.

It looks like Erlang will be good for doing a PoC but that will just show whether it's worth spending 2-3 years writing the compiler.

Re:A Question

[Anonymous Coward]

The question is: how do I develop this while keeping the mortgage paid and making a profit?

Umm...work on it in your free time?
Next question?

Re:A Question

[Anonymous Coward]

Which is what I have been doing. I don't get a lot of free time and things this challenging take a lot of concentration. I reckon it'll take about 15 years at the current rate.

Re:A Question

[Anonymous Coward]

I reckon it'll take about 15 years at the current rate.

Are you familiar with "The Art of Computer Programming" by Donald Knuth? Your 15 years is but a blink of the eye to the good professor. I've been waiting for his Volume 7 since about 1972 and, sadly, I'm still waiting.

Does anyone know Knuth's schedule for the remaining volumes of TAOCP?

Re:A Question

[Anonymous Coward]

I'll ask him and see if we can do a simultaneous release in 15 years' time.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

WTF is wrong with California?

[Anonymous Coward]

Seriously, I use to think that republicans were just idiots for giving California such a hard time. But, seriously, now I wonder, just what the hell really is wrong with California?

People there seem to have no basis at all in reality and just think because you wish it, it can and should be so. More architectures? Is he insane?

More languages? Aren't there at least two or three new languages that come out almost on a monthly basis, none of which are better than the one from yesterday?

The problem is not the lack of language or architecture. It's the opposite - it's the distraction of existing intellect away from improving what exists to focus on unicorn fantasies that were proved impossible or impractical during the development of those existing ones.

FFS, maybe it really is time to let California secede so they can invent all the solutions they want to problems that don't exist. Then they can create new problems to justify those solutions and be happy in their poverty.

Re:WTF is wrong with California?

[fredrated]

What twisted you knickers so badly?

Re:Idiot. We have enough stupid languages. RISC su

[110010001000]

Um, all modern processors are RISC. Careful who you are calling an idiot.

Software Devs

[Anonymous Coward]

This all points back to software devs. I've spent 2 decades dealing with low-level drivers and optimizations in assembly language. Now, not that I would expect developers to write assembly language, the problem I run into is that software developers of high level languages can't even write efficient code at their level. On top of that, they don't even understand how the language stack works, what code constructs give better performance in one language versus another. In addition, they can't even profile their code anymore or look at logs.

If anything needs changing, it's software developers first. They keep eating up all the computer resources and say "get more this/that for your computer." No, pull your head out of your 4th point of contact and learn to write efficient code. We were doing this shit in the 90s all the time. We even advertised for assembly programmers in NEXT Generation magazine, constantly!

While there's nothing wrong with using high-level languages, programmers today have lost the art of what it means to be lean and mean. I don't hire any developer unless they can demonstrate they know the stack for the language in which they use.
Me: "Oh, no assembly language experience?"
Applicant: "Oh, no. Is that required here?"
Me: "In rare cases, but I'm trying to understand if you even understand how a computer works at a fundamental level. In fact, have you ever worked with state diagrams?"
Applicant: "No."
Me: "Okay, you write an application that simply opens a file. What are the failure modes of your application and the opening of the file? Can you draw a state diagram for this?"
Application: "A flow chart?"
Me: "No, a state diagram. Given a set of inputs, I want you to diagram all outputs and failure modes for each state."

Applicants could answer these questions in the 90s and early 00s, but rarely anymore. I blame software devs for this problem. Hardware engineers are always having to pick up the slack and drag everyone up hill because software devs can't pull their own weight.

Re:Software Devs

[Anonymous Coward]

Modern high-level developers often work in businesses where iteration speed is vastly more important than performance. Even correctness in the last 2% of cases is optional. The code has an 80% chance of being thrown out for business reasons anyway, so why spend so much time making it perfect? Building a system that is easy to change quickly is ideal, even if some of those changes have to be quickly rolled back or patched.

Fault-tolerance has also moved up the stack. It is no longer put into applications, but into the architecture. Why should the code attempt to recover from an error, when we can kill the process, fail the affected requests, and start a new one? As long as requests are idempotent, and the processes are stateless, and the storage is transactional, this is fine.

If you are a low-level developer, you probably feel sick reading that. You are trained to get all the little details exactly correct, and you take pride in your craftsmanship. But high-level developers aren't all a bunch of spaghetti-code-vomiting monkeys. Many of the behaviors you despise are effective adaptations to business realities.

Re:Software Devs

[Dorianny]

Today's general purpose CPU's use their own microcode to control the processor. Your carefully crafted assembly is no longer directly controlling the CPU, it is being converted into whatever arcane microcode that CPU family is using.

State diagrams on the other hand are still extremely useful

Re:Software Devs

[Anonymous Coward]

You are very confrontational in that dialogue.

Re:Software Devs

[Anonymous Coward]

> You are very confrontational in that dialogue

Not by '90s standards...you know, the pre-snowflake generation?

"He asked me about my experience! What a jerk!"

Re:Software Devs

[Anonymous Coward]

It's not developers, it's CS programs. They've stopped offering operating systems. They rarely offer assembly programming anymore. They aren't even taught parallel programming in the era of multicore.

The one thing they do teach you is that you can throw hardware at problems. That's not so true anymore and when it is, it requires a lot of smart, clever programming.

Hardware people give us headaches too. Look at all the hacks and workarounds in drivers now. Hardware is garbage. We get spectre and meltdown. Shortcuts for speed cause us security grief.

You read my mind, sir!

[Anonymous Coward]

My thoughts exactly. In what hell-less world dies he think those of us who are willing and able would ever be incentivesed to do it.

Fast Enough For Whom?

[Anonymous Coward]

Your chips may be fast enough for you, but it still takes far too long to do the things I need done. Days, weeks, months...

Faster chips help everyone. They not only speed up individual processes, but that extends far and wide to things like faster networking(more bandwidth), reduced costs, better opportunities for the future.

While I have always FUCKING HATED the moronic programmers that proclaim 'CPU/Memory/Disk is cheap so what does it matter if I layer on another four bloated frameworks?' I absolutely want some assembler level compact and fast code. But, even the fastest code will further benefit me with better chips.

Re: Fast Enough For Whom?

[Anonymous Coward]

I agree this is a "tastes great less filling" type of debate.

The goal is faster chips and efficient code, so we can do greater things.

When will my laptop be a quantum computer?

[Streetlight]

I assume such a laptop would be pretty fast.

Re:When will my laptop be a quantum computer?

[Actually, I do RTFA]

Quantum computers will be slower for most tasks. There are some tasks for which they will be much faster.

Re:When will my laptop be a quantum computer?

[Anonymous Coward]

* If quantum computers can be made faster than classical (or even at all). Right now most demonstrations are of slow small bit pairs that operate hundreds or thousands of times slower than classical.

The problem is nobody noticed it

[damn_registrars]

I know we've said this before, but I think we really have reached the point where the overwhelming majority of users can no longer tell, use, or appreciate an increase in processing speed. It wasn't that long ago that it was necessary to have a cutting edge CPU to do a lot of important end-user tasks. Now I do the majority of my work - which is vastly more computationally intensive than work I did not long ago - on my laptop. This isn't a cutting-edge gaming laptop or workstation replacement laptop either, it is a ThinkPad that I bought for ~$1,000 a few years ago.

Can we make processors even faster yet? Sure. Can we make code even faster too? Certainly. Will most uses notice it? Almost certainly not.

Re:The problem is nobody noticed it

[110010001000]

"Can we make processors even faster yet? Sure"

No, we can't. That is the point. The processor you get next year will only we marginally faster than the one from this year.

Re:The problem is nobody noticed it

[Anonymous Coward]

Same thing as 20 years ago, many people are starved for memory (RAM) and don't know it. e.g. I was asked to fix a computer getting very slow but it has an incredibly fast CPU (Sandy Bridge i3 on laptop). I do maintenance shit on it (uninstall mcafee update windows...) turns out there is nothing wrong at all but it has "only" 4GB RAM which I think is the real culprit. SSD would "fix" it probably but if the user just swaps on SSD that's lame.
You can buy a $1000 high end laptop with 8GB soldered RAM. Shit.

Re:The problem is nobody noticed it

[Roger W Moore]

No, we can't. That is the point.

Define faster. The single core performance may only increase by a few percent but the number of cores keeps increasing. So if your algorithm can use multiple cores it will be faster if not then it won't.

Re:The problem is nobody noticed it

[WinstonWolfIT]

Ditto. My Surface Book Pro is only faster than the Thinkpad it replaced due to faster SSD architecture. Both were bought at a $3k price point (work allowance) and gotta say I prefer the lighter SB even if its keyboard and no mouse nipple almost suck.

Re:The problem is nobody noticed it

[damn_registrars]

As bad as the SB touchpad may be, I would bet money it's better than the touchpad I've had to deal with lately when helping a colleague who uses an HP laptop. Apparently she ordered a "gaming" laptop from HP as it was the one on the company list under "high performance". That touchpad is so infuriating awful that I won't meet with her unless I have a mouse with me. To make it even worse (as hard as that is to believe) it has a touch screen as well, which I found out by accident once. Why anyone thinks a touch screen is a good idea on a laptop is beyond me; I have yet to see anyone use a touch screen on any device anywhere for serious work, and it often only impedes work.

Re:The problem is nobody noticed it

[Anonymous Coward]

Depends on what you're doing.

Options:

1. Increase L1 cache

Less time spent fetching from main memory, more time working.

2. Increase register widths and depths

If you can operate on double width registers, you can avoid the multiple operations needed to perform operations on extra-long numbers.

If you can do any operation on an array of inputs simultaneously, you can do the whole lot faster than looping via instructions.

3. Share logic

Instead of four isolated cores, have pools of logic that would match to four cores and then have four thin cores that can use as much of any pool as they need for bulk work. Some CPUs do this.

4. Wafer Scale Architecture

WSA has been on the horizon since the mid 1980s. But you could fit 1024+ cores onto a wafer.

5. GaAs

Seymour Cray loved the technology, but it wasn't good enough back then. These days, it would be easy enough to make a CPU with it.

6. Remove the cache

It's hard to make a hybrid chip. If you had the cache on different silicon and ran lines directly from it to the cores, you could shorten the average distance as well as free up space on the CPU for more logic.

7. Add CSP to cores where absent

Communication between threads or processes takes a lot of instructions, is often buggy and may as well be done by the CPU because we know how to do that.

8. Itanium 3 + Cell idea + Transputer

The problem with the Itanium 3 (now they'd fixed all the other issues) was that nobody knew how to program it. The problem with the Cell was that you couldn't do anything useful. The Transputer was just too obscure.

Solution - design an Itanium 3 refactored so that different concepts are modularized and then use the Cell idea to distribute modules across many cores. It's easy to program any given type of core, a multipass compiler can therefore compile for all of them with minimal complexity.

Now, the Transputer had a wonderful idea for SMP, you just connect the processors with a one line serial bus. That's it. These days, you can make that a bit wider - two lanes for async. No upper limit. Plug together CPUs like Lego blocks.

Moore's Law, parallelism and single thread

[SpaghettiPattern]

Can't read the link so I assume it's about parallelism.

I think we welcome languages that encourage users to divide a problem into many smaller ones. But do we really need them?

What I mean to say is that the value of software lies in the APIs and libs you develop. Having it perform well in a parallel environment takes a bit of clever thinking but most of us will hack it.

There are quite a few programming models and frameworks that already allow astonishing things to happen in parallel. What is Patterson hinting at?

Moore's original law on the number of transistors in a dense integrated circuit is over. But there are sufficient derived/similar observation for parallelism. So, well designed parallel programs will still run faster or cheaper in a similar way as Moore observed more than 50 years ago.

Re:Moore's Law, parallelism and single thread

[Anonymous Coward]

Yes, and if it's about parallelism, then at least the /. summary is wrong. Sure "single program performance only grew 3% last year", if you correct "program" to "thread", but we get more cores every year now. And multi-core is so commonplace, even smartphones routinely have them.

I still suspect that we cannot fully make up with parallelism, what has been eroding away from Moore's Law. At least not in every case. However it's not crazy to be thinking about bog standard PCs with dozens or hundreds of cores in the foreseeable future.

There is no way that software engineering has fully mined parallelism, not even close. I'll bet there are hundreds of top-ranked software programs, used by millions, that have no parallel support. None at all! And simplistic parallel designs put artificial limits on how many threads they will support, yet I'll bet that the real world of extant parallel software is dominated by simplistic parallel designs.

Lots of people here on /. are quick to quote Amdahl's Law as a barrier to parallel design opportunities. Yes it's a constraint, but that's far down the road as a major concern. I'll bet optimized supercomputer programs run into Amdahl's law fairly regularly. Your browser though? Your spreadsheet? Your database? I very much doubt that.

https://hpc.llnl.gov/tutorials/introduction-parallel-computing/limits-and-costs-parallel-programming

The 30 million line problem

[technosaurus]

In his blog https://caseymuratori.com/blog... Casey Muratori advocates the move away from drivers to instruction set architectures (ISAs). Back in the day individual software could boot the entire computer in relatively few lines of code and still do its job while fitting on a single sided, single density floppy disk. Even today, you don't see game vendors making bootable Linux versions of their games that could theoretically work on both Mac and Windows, but I get his point.

Re:The 30 million line problem

[Anonymous Coward]

A bootable linux version of a game is literally the worst idea ever - it won't have driver updates (so among other things it won't work when the new graphics card or motherboard comes out), it won't let users use Discord or streaming software or capture cards at the same time, it would be stuck with the shitty Linux drivers nVidia puts out. And instead of having stupendously fast NVME drives it would have to load off a USB stick (I assume you don't mean a DVD, since games are bigger and nobody has a DVD drive anymore).

Re:The 30 million line problem

[nine-times]

I'm not sure I understand, but I don't really see the point in having individual applications be bootable on hardware. If anything, it'd make more sense to me to push more stuff from the OS into the firmware so that the firmware would present a standard set of APIs/protocols and the OS wouldn't need to worry about drivers. And then, in turn, standardize APIs across operating systems so that cross-platform apps would be easier.

Either way, good luck getting any meaningful change out of the computing industry. There are too many powerful entrenched players who aren't interested in playing well with others.

Re:The 30 million line problem

[technosaurus]

That was his point exactly.

Re:The 30 million line problem

[technosaurus]

I think that was kind of his point too. He goes into great detail on many aspects of a new ISA and even discusses the vendor issue toward the end. I highly recommend the video.

Re:The 30 million line problem

[WorBlux]

BIOS/VGA are pretty damn standard at this point, Most of the bootable games aren't trying to do 3-D AAA style, but retro 2-D style. And even if hardware moves beyond that, there's alwasy QEMU.

Re:The 30 million line problem

[nine-times]

Yeah, it's weird because he's sort of saying the same thing, but sort of saying the opposite. And I have no doubt that he knows more about the how these things work, but I think it's possible that this is an issue where technical expertise blinds people to some practical considerations.

And what I mean by that is that he seems to be arguing (as far as I understand) that a lot of our problems come from having operating systems that abstract programming from the hardware, and the solution is to have programmers write things to basically run directly on the hardware. And that's all well and good for the programmers who are happy to handle all of that stuff, but I suspect that an awful lot of programmers need or want the abstraction.

He sort of acknowledges this when he talks about having low friction by having APIs like DirectX and Vulcan. I'm not a genius programmer, so I want the abstraction of APIs and frameworks that let me just think about what I want the software to do rather than how, on a machine level, it's supposed to do it. So I think you need that abstraction.

I maybe we're saying the same sort of thing, but I might not really "get it". I just don't really understand, for example, why printer drivers are still such a problem. There should be a standard set of instructions that the OS can send to the printer to say, "This is what I want to print," and then the printer should know enough to know how to print it. I feel like it's kind of the same thing with keyboards, mice, hard drive controllers, network interfaces, wifi chipsets, etc. Like why can't the OS tell the NIC, "I want you to send this information out according to this protocol, or whatever, and have the NIC know what it needs to do to send that data out? Why can't the OS tell the storage device, "I want you to store this data" and the storage device know how to do that?

So in that sense, it seems to me that, instead of having programmers more involved in the nitty-gritty of hardware, the hardware should already present a pretty abstract interface to the OS, and the hardware should hard firmware and whatnot to optimize those requests without the OS needing to know much about the nitty-gritty of what's going on in hardware. And then the OS should basically be responsible for abstracting all of that hardware stuff, to the point of providing libraries, APIs, and frameworks for app developers, so applications can be made easily without knowing much about what's going on in the OS or hardware.

Because I feel like this guy is a super-nerd (I'm saying that in an admiring way, not derogatory) who wants to deal with all the hardware stuff so he can get games running as fast as possible. From my point of view, I'm much closer to a layman and I care less about games and I don't have a huge problem with performance. I just want to make things simple, and for things to work without problems. It seems to me that the solution is try to try make things modular, and push the nuts-and-bolts optimization close to the hardware, done by only a few really amazing programmers who really know what they're doing. And then assume we're going to have a bunch of dumb programmers who don't know what they're doing, but just know what they want their program to do.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Waiting for cheap RAM

[Anonymous Coward]

Really what I want is a dual core with 32GB RAM. I don't do nuclear weapons simulations I just want to run a web browser and not have it not work anymore because of memory leaks in the browser or OS. Meanwhile I want to be able to run video players, be it standalone or another web browser such that I can play this video with no interruption because of swapping gigabytes on HDD, and also run old or cheap video games. And I'm not yet doing anything useful.

Re:Idiot. We have enough stupid languages. RISC su

[Anonymous Coward]

Sure. So Moore is no more. What are we supposed to do now? If you think RISC sux, then you haven't met x86_64.

The 'industry' does not seem to have a requirement for new computer architectures or ngeneral-purpose programming languages. So maybe the answer is to design custom processors and custom programming for each app to solve the problem of software piracy. The new Wintel Fenestrium will have a reduced instrucion set, consisting of of Word, Excel, Outlook, Edge, PowerPoint, Access, Paint, Skype.

Maybe we can eliminate shared libraries

[Tangential]

Maybe can eliminate shared libraries, dynamic linking and other archaic constructs that came into existence to protect scarce resources like RAM and disk space. Let's put each process in its own 'jail' like existence with closely monitored mechanisms for communication between processes.

Re:Maybe we can eliminate shared libraries

[reanjr]

RAM is still scarce if you stop using shared memory. Shit, RAM is still scarce on a Mac even with shared memory...

Re:Maybe we can eliminate shared libraries

[Anonymous Coward]

Turn of Slack...

Re:Maybe we can eliminate shared libraries

[Anonymous Coward]

The shared libraries and dynamic linking which you are refer to as "archaic constructs" allow you to patch security holes in a single library that will by definition of being dynamic, plug the same hole in every application that uses it. Otherwise, you're stuck with archaic constructs like island blobs of programs stuck in various states of security vulnerability. With a single library patch, you've protected your entire system without having to wait for dozens or more individual applications from individual developers re-compile and distribute their individually patched programs, or worse recompiling you're entire world to include the fix. That's why you care about dynamic libraries.

Admittedly, dynamic linking has it's own set of problems. But everything is a balance of pros and cons. Those are the things you learn when you grow up.

Re:Maybe we can eliminate shared libraries

[Anonymous Coward]

Yes but who will need more than 640KB of RAM?

Re:Maybe we can eliminate shared libraries

[Anonymous Coward]

Oooh boy that gust of wind nearly knocked me out of my chair!

Re:Maybe we can eliminate shared libraries

[Anonymous Coward]

Shared libraries weren't just used for RAM and disk space. The problem with Shared Libraries is when they don't follow an API or have no versioning scheme. Then they can't be updated in a safe manner. That's the main reason to use shared libraries. When you need to patch software that uses the library, you just patch the library. Not entire programs.

Oh! They Failed! Ugh!

[Anonymous Coward]

Various alternate architectures have been tried out over the decades. A lot of other programming models have been tried out as well. They all basically failed or live on only in niches because people could not hack coding for them.

Performance increases for most tasks are over. Deal with it and stop proposing silver bullets. It only makes you look stupid.

So what! Why in the 21st century are we still TYPING code?!

It's like if we were still using patch cords in the 1980s to program computers.

Seriously.

Human computer programming interfaces have been stagnant for 40 years now. But hardware has progressed much faster.

Text programming languages? How 1960s. How droll.

In the 21st Century, I would expect to program computers with anything BUT something that I can use a 1950s teletype to program.

Computer interfaces haven't improved in 50 years.

We're stuck.

Re:Oh! They Failed! Ugh!

[Anonymous Coward]

What a completely naive response.

We program in code because it is easy for the computer to transform into instructions.

It is not the text vs voice that is the issue, it is the language itself. Natural language is difficult for computers to translate on its own, let alone to then also layer upon it the comprehension to turn that into instructions.

And once we hit that point, Skynet is just going to turn to you and say "do it yourself".

Re:Oh! They Failed! Ugh!

[WorBlux]

Of course it's text, what else would we use. Written languages are like 5,000 years old and have always been more expressive than pointing and gesturing.

Sure there are a few visual programming suites, but they are best suited for stream processing, and not for heavily branched general purpose code.

And a brain interface is a much harder problem, and trusting AI to write code could have devastating results.

Re:Oh! They Failed! Ugh!

[cpurdy]

What a completely naive response. We program in code because it is easy for the computer to transform into instructions.

... and more importantly, because humans can absorb information about a program faster from text than they can absorb information via other means.

Among other reasons, it's why we still have books in 2018.

Re:Oh! They Failed! Ugh!

[gweihir]

Written language is a mature technology that is exceptionally well optimized for interfacing to humans.

Having an AI write code would require strong AI and that is not even on the distant horizon, despite the current demented hype where things that have been known for half a century or longer are suddenly called "AI".

Re:Oh! They Failed! Ugh!

[Bengie]

Coding is just a transcription process. There's a fundamental issue that in order to make a system that can code for you, that you need a way to unambiguously tell that system what you want it to do. Guess what coding is. Telling a system in an unambiguous way what you want it to do. What we really want is a way to further divorce programmers from the nitty-gritty details that consume most of our coding time.

Languages up to this point have done a decent job of just that by hiding ASM from the coder, but we've hit a brick wall. We keep creating new specialized languages, but each has a trade-off and most of the time they're specialized in order to deal with specific back-ends or front-ends, not so much as general purpose.

I personally think the first effective usage of AI to enhancing coding is better refactoring tooling. It can be a time-consuming operation, especially in large systems. Imagine instead of refactoring bits at a time, you can do the entire system in one step and have it ready for the next release. Could be done by assigning attributes to methods and variables and specify guarantees required. You still have an architectural and design issue that you have to specify the correct attributes, but even if you miss one, it could be as easy and adding the missing or changing an incorrect one and letting the AI restructure the system.

Re:Oh! They Failed! Ugh!

[mschaffer]

Why in the 21st century are we still TYPING code?!

Because we are too busy complaining that we don't have jet packs or robot butlers, and we still pay for electricity.

Re:Oh! They Failed! Ugh!

[gweihir]

And fail. Coding is far more than a "transcription process". If it were, the input to that process would need to have the same level of detail as the output. Guess what, in that situation it is less effort to code directly than create that input.

What actually happens is that coding transforms a somewhat to very abstract description into a concrete one in a programming language, respecting aspects of performance, reliability, security and others. It is a process that requires insight and some degree of creativity. Approaches to "program" on the level of a formal specification language have failed some 40 years ago or so, because doing this is more effort than coding directly and the translation result is not very good. The same still applies today.

And no, "AI" cannot do refactoring, because that requires coding skills and no machine in existence has those or will have those for the foreseeable future.

Re:Oh! They Failed! Ugh!

[Bengie]

What actually happens is that coding transforms a somewhat to very abstract description into a concrete

That's called design. Coding is literally the act of write code. Code is how human currently communicate with computers and potentially other humans. "Designing" code is taking an idea and thinking of a way to express it in code. Design is something rarely done. Most people just get to working pumping out code.

Re:Oh! They Failed! Ugh!

[Anonymous Coward]

What actually happens is that coding transforms a somewhat to very abstract description into a concrete

That's called design. Coding is literally the act of write code.

No, he's correct. Coding IS writing the code, but tradtionally you create the design before you start to code. You can design with flowcharts, dataflow diagrams, UML, pseudocode, etc. without writing any actual code.

Nowadays these Agile methodologies treat design as "emergent," meaning you start building before you know what you're building. Because it's iterative, you change the design as you go and it's supposed to evolve into the optimal design over time.

Personally, I think that's crap. I'm old-school: you can't build a house without a blueprint (if you try it, you end up with a crappy house that looks terrible and falls apart).

Moore's law is working more or less fine, thanks

[williamyf]

Transistors are doubling every 24 months or so, on par with moore's original enunciation of the law, and slightly off the 18 months of his revision of said law.

What is not working anymore is _*"People's Interpretation"*_ of said law, that dictate that computers sould be 2x faster every 18 months. Moore never said that. He only said that in a given sqr centimeter of silicon, the optimum number of transistors would double every 24 months. then he latter revised the number to every 18 months.

When Moore's law was in full swing, say, in the 80's and 90's, making transistors smaller every 18 months allowed computer and processor architects to make the transistors switch faster, consume less power, we could pack more features, and make the processors cheaper, all of that at the same time. So, we had a Mhz race, on top of wich we integrated things in the processor, first paging unit, the Caches (L1 and latter L2) and Math coprocessor, then the memory controller, and more pipelines (starting with the UV pipes) and we depeloped new features/functionality, like protected mode, IA32, MMX, SSE, AMD64, et al, all of this at the same time. Please notice that all of that was made possible by moore's law, because, to implement most of those things, one needs, you know, more transistors...

At some point in the mid 00's, we hit the first roadblock, and it was not possible to make the transistors switch faster without consuming a significant amount of power, so, one dimension less.

But moore's law did not stop. We still were able to double the number of transsistors every 18 months. That's why we were still able to pack more features (SSE*, AVX*, transactional memory, virtualization support, advanced Ecryption support) and more cheaper things (higher core counts, a GPU, PCIe controllers, ETH controllers and more) in the processor for the same price. But not with increased Ghz. And the SW world has been slow to make use of many of those new features/things, it seems that performance has stagnated. If moore's law had stoped, we wouldn't have been able to increase core counts (and cache, and all the other stuff) as we did, because all those things require, you know, transistors to implement...

Now, in 2018, finally, the REAL Moore's law is strugling and limping (ask intel 10nm and GloFo 7nm people). It has a few cycles left (ask the TSMC and Samsung 7nm people), but not many more.

In the meantime, yes, new architectures are worthwhile, fine and dandy (and more publishing and headline worthy), but a more inmediate thing would be to make better use of what we already have (SSE, AVX, GPGPU, Multiple cores)...

JM2C, YMMV

trim the bloat

[Anonymous Coward]

I Am Not A Programmer, but I hope the diminishing returns of hardware performance means that software will be better optimized and less bloated. Every year, a new version of some creative software comes out. For many, many years, the software became fatter and slower, but hardware got faster. This produced the illusion that the software was staying at the same level of performance, when in fact it was getting worse every year. I hope the end of Moore's Law will mean that software companies will prioritize efficiency over useless features that no one uses, but merely give the market department something to crow about.

Re:Idiot. We have enough stupid languages. RISC su

[Anonymous Coward]

So, shit is a universal word, no comma are needed, you fucking shit?

IT'S TMIE

[fluffernutter]

I think it's time for teleporters, holodecks, and replicators. Is everyone with me??

Another day, another new language

[Anonymous Coward]

And another new architecture.

There is an old saying, "It's not the pen you use; it's how you sign your name."

The singularity..

[mrwireless]

so.. slightly delayed then?

Re:Idiot. We have enough stupid languages. RISC su

[WorBlux]

Right anymore the CISC target is an abstraction, that lets the decode unit in the chip one last chance at optimization before sending data to the computational assemblies. 80% of the out-of-order speed advantage comes better static schedules on chip. And most of the circuitry on a modern chip is dedicated to figuring out what to do next and getting ready to do it, vs actual silicon dedicated to is. Something like a VLIW can get a lot more performance/watt by letting the compiler do the scheduling and set-up, at the penalty of being poor at branch heavy code.

Re:Idiot. We have enough stupid languages. RISC su

[Anonymous Coward]

Idiot.

You do realize that your CISC Intel/AMD instruction set architecture all gets converted to RISC internally for efficient and fast execution.

Never mind all this human assembler programmers. I bet none of them even knows more than 10% of all the instructions available today in x86.

IA432?

[Anonymous Coward]

bitsavers.org has a huge quantity of documentation on it available. I was looking at it a while back as something I would like to make an FPGA implementation of, and if it works as expected, see about updating it to support real 32/64/128/256+ bit addressing schemes.

It was designed with limitations similar to the 286 but with 1TB of virtual memory addressing. Given some updates it could be a very interesting secure processor today.

Re:IA432?

[TechyImmigrant]

It was out of step with the direction of OS development at the time. This is one of the reasons it didn't catch on.

Many of the people who worked on it are now retired or dead.

As a CPU design with a security focus and with specific security guarantees built in, it was indeed ahead of its time. We surely are finding we need such ideas in CPUs today.

Re:Idiot. We have enough stupid languages. RISC su

[Anonymous Coward]

Compiler do the setup/scheduling ? That's was tried, and failed miserably - it was called Itanium.
If you let the chip itself reorder instructions and fill the pipeline with ops that are ready-to-run (all inputs available), you get MUCH better performance (and can have effectively a VLIW backend). This is akin to what the current X64-64 chips from Intel and AMD do.
That being said, the instructions being actually scheduled to functional units are RISC; what CISC instructions exist are most microcode sequences of RISC instructions that can be sent thru the execution pipeline. For most instructions, the scheduling ISN'T static, which is why it works as well as it does.

Re:Idiot. We have enough stupid languages. RISC su

[Anonymous Coward]

You're a fucking idiot and anyone else who keeps on drumbeating the "DURR X86 IS RISC BECOS DECODE ENGINE" is a fucktard.

x86 is **CISC**. It might be *translated internally* to RISC, but if you can't specify those micro-ops, it means fuck all to the ISA or programmer, except you have more side effects of instructions you have to consider if you are doing hand assembly.

The *instructions* you can actually specify are CISC, so the exposed architecture is CISC. Microarchitecture is not something controllable by the programmer except indirectly.

Would love an x86 system with the uops exposed as an ISA. Then we're talking actual RISC in a meaningful sense.

Re:Idiot. We have enough stupid languages. RISC su

[Stephan Schulz]

Trouble was, RISC solved a problem that was temporary - lack of space on the silicon.

There is the core of your misunderstanding. The idea of RISC was not to use fewer transistors, but to have a simpler, more orthogonal instruction set with homogenous stages all running in about the same time to enable high clock speeds and pipelining. And yes, there are excellent RISC designs out there - ARM is one, and so is RISC-V. "CISC" nowadays is 99% RISC - they copied the large register sets with x86_64, and they have broken down the CISC instructions into microops that are executed RISC style since roughly forever.

which moore's law

[Anonymous Coward]

Moore revised his BS multiple times on and off record.
Also, there' little to create in comp. Arch. from the "new" pov.
What will happen is that there will be hybrid architectures, combining RISC CISC ISAs and VLIW/OoO/In Order/e.t.c. approaches.
One example of the post 2010 era of comp. arch. is the DSP arch that Samsung uses in their exynos SoCs, which has an additional engine to schedule the instructions (from the compiler because it's vliw) using data training from various workloads... and even that is not new. we've been studying binaries in order to decide the stronk and the weak point in an architecture.
The final solution for better performance and less power consumption is dedicated h/w for everything and h/w acceleration libraries for everything.
AMD tried to do that with the APUs and people laughed at them.

Patterson should talk about how software lags behind everything, despite being more agile and easy to change.

No it doesn't.

[Anonymous Coward]

You mean "logistic growth". Different thing.

A different direction?

[Anonymous Coward]

I am of the opinion there is still plenty of innovation to be had that can increase our processing capabilities, although maybe in a different direction that Moore's law directed us so far.
For example, using Trinary instead of Binary for Storage systems or network communications. Switching from Silicone in chips to some other substance. Or maybe a push for more efficient programs, or offloading smaller tasks to dedicated low-power cores (Already doing this for some smartphones). There's all kinds of different directions we can go, and a slowdown will only drive exposing more creativity and solutions in these other areas

Re:Exponential growth always hits an inflection po

[thegarbz]

Of course, but have we hit that inflection point? By all accounts were only slightly behind the times in transistor count in ICs with them doubling every 3 years now instead of every 2. Still very much a large logarithmic gain.

Faster and Faster Computers for Bigger Systems

[neoRUR]

Why is is that there are always those people on here that think we don't need anything new or faster?
Have you never run any development system and think, OMG, why is this taking so long?

We need way faster CPU's and computers, In fact we need Quantum computers.
I would love to compile 1.3 million LOC for 10 different platforms in 3 seconds.

The faster we go, the bigger the systems are they we can build. Try running a Neural Network the size of your brain!
A NN with 10^11 (one hundred billion) and 10^15 synaptic connects on your computer today...You can't...
We will need to make ones 10 to 100 times the power..

Re:Faster and Faster Computers for Bigger Systems

[Anonymous Coward]

Quantum computers won't solve your compile problem; better parallelism will. Similarly, your NN problem won't be addressed with Quantum computers either.

Sorry, reality sucks.

Re:Moore's law is working more or less fine, thank

[91degrees]

Yes. Some tasks have got a lot faster with the standard box of chips (primarily tasks that take advantage of GPUs), and a lot of tasks are faster on a single processor, as long as they take advantage of multithreading.

Honestly I'm a little surprised that clock speed increase seems to have slowed so much but an 8th generation i7 will knock compile times down a lot from a first gen.

Duuurrrr

[Anonymous Coward]

Oh oh oh CDR
If today's games were threaded the same as when your machine was new. They would not run well on your box. Be honest. What FPS do you get on doom4 on reasonably high settings?

CDR: AI will never go anywhere it's super dumb and full of hype
Also CDR: I don't know why this guy is saying we need new architectures and languages? Word and Edge work great on older machines!

Don't use C/C++

[Anonymous Coward]

Computers aren't getting any faster. But don't use C/C++ -- instead, invent slower and slower languages. Let's try Visual Python Script# on Rails.

Gaming is definitely held up by slow CPUs

[Anonymous Coward]

When is the last time gaming was held up by processing? Going to 4k gaming is an exercise in diminishing returns.

You're looking in the wrong direction. No, over here.

No, you're still looking in the direction of more pixels. This way. Yes, over here. That's right. Yes, I assure you, you're in the right place.

I wanted to show you a game. Yes, a game. Dammit, quit asking: yes, you're in the right place, I promise.

The name of this game is Dwarf Fortress.

Uhm Actually

[Anonymous Coward]

We are at the performance scale he's talking about,
  it just so that the software got so bloated layered convoluted and abstracted
  that it works as if it was running on computers from 20 years ago

YMMV

passphrase : faculty

Re:Idiot. We have enough stupid languages. RISC su

[Seven Spirals]

Well, I have to admit you are right. My beef with RISC isn't so much any problem with an internal microarchitecture, it's the lack of handy ASM instructions I'm used to from other platforms (most notably the VAX and the 68k). When you spend time coding on the 68k or VAX then switch to a RISC platform, you feel the suck. However, I do question your assertion that RISC was just have a more machine-clean ISA. There *was* a lack of space on silicon in the 1990's and some of the motivation to "go RISC" did stem from that fact, too.

Whut??

[Anonymous Coward]

"...he cannot let go of the old, failed ideas..."

So that explains why he's calling for new ideas then! Right, got it...

Re: Whut??

[Anonymous Coward]

Lol!

My big concern is nothing about speed

[k6mfw]

It is computers are becoming more tied to the The Cloud where to do anything the computer has to be online. And then there's constant upgrades to upgrade in order to meet the next upgrade (and pay more money). For most of my stuff I don't need a faster computer, just something to do stuff without having to deal with downloading crap I don't need.

Re:Idiot. We have enough stupid languages. RISC su

[Seven Spirals]

Bullshit. Fool. I know several ASM programmers who definitely at least 98% of the modern x86_64 ISA like a fucking encyclopedia. I mean give me a fucking break, it's not that huge. The only parts that are even marginally hard are the SIMD ops. It's easily learned by a kid (taught my brother ASM when he was 12). It's the design patterns and memorizing lots of ROM holes on weird architectures that make ASM a challenge. Anyhow, do you even code, bro? I program in C and ASM about 4 times a week. You?

Re:Idiot. We have enough stupid languages. RISC su

[Anonymous Coward]

Umm, no. People could write in anything, the simpler instruction set meant that program binaries would be larger but faster. More real estate on the CPU could be put into registers, L1 cache and operand width. Different people used different choices.

I don't give a rat's about ARM or PA-RISC. MIPS64, which you'll know all about from SGI, is a better architecture. Not tried the MIPS R8000. T9000 was interesting but no longer exists.

SPARC is a genuine RISC architecture, and by extension so is the UltraSPARC and the UltraSparc T5. Wanna tell me about how only C programmers use an UltraSPARC?

All modern Intel processors are two-layer - a RISC core and a CISC translation layer.

As for compilers vs programmers, want to put that to the test? In 1980, or 2000, you'd have been right. Programmers could hand-turn code better than any compiler. These days, the top compilers can rival any programmer because the compilers can handle ooo execution, cache coherency, cpu starvation, imbalanced caches and a thousand and one other consequences of multi-core computing in what is in effect a hybrid heterogeneous system.

Further, compilers can remember to profile and rebalance.

Even further, copy the same source onto a different architecture. May be a CPU upgrade. Your hand-turned optimization may now pessimize (see hacker's dictionary), whereas the compiler will simply optimize differently.

Also, I'm not sure if you've ever written in Ada, Occam, Erlang or Haskell, but hand-turning isn't really an option.

Re:Idiot. We have enough stupid languages. RISC su

[Anonymous Coward]

I'd rank MIPS as one of the best current RISC architectures.

StrongARM kind of vanished, although it was an interesting enhancement to ARM.

All SPARC architectures (including the UltraSPARC T5) are pure RISC.

Re:Idiot. We have enough stupid languages. RISC su

[Anonymous Coward]

SPARC is RISC. Ok, late 80s, but a bit before silicon crunch.

Acorn RISC Machine was 1985.

Inmos Transputer T400 was 1983, and definitely not a silicon real estate issue.

There may have been a space motive by others in the 90s, but the battle had been raging for seven plus years by then.

Think of all the waste

[mineral2]

"people would throw out their desktop computers that were working fine because a friend's new computer was so much faster." Just let that sink in, then think about it in the context of all the e-waste pollution we've created. Perhaps this is now a good thing that people can hold onto their computers for 4 - 8 years until the components actually wear out or become unsatisfactory.

What? No!

[Anonymous Coward]

No, They haven't stagnated. My daughter programs in Scratch. I use labview and VBA (shut up, I work for a remarkably retarded organization). Those are most certainly not Typing code. However, tying is better than all of the other things that have been tried, except that things that aren't typing.

Intellectual dishonesty

[Tough Love]

Patterson's argument is blatantly intellectual dishonest... he talks about single program performance as if single programs are never parallel these days. He mischaracterizes Moore's law as being about single program performance (his creative definition). It is not, it is about transistor density, which continues to increase roughly according to Moore's law, and with no end in sight. Sure, process node shrink is slowing down, but parallelism is increasing rapidly, roughly balancing that. And 3D stacking is already a thing, it will accelerate. Then there are non-silicon technologies like carbon nanostructures. I don't see Moore's law halting for at least the next 20 years.

I'm sure he has a point, but faulty rhetoric detracts from it.

Re:Idiot. We have enough stupid languages. RISC su

[Anonymous Coward]

Compiler do the setup/scheduling ? That's was tried, and failed miserably - it was called Itanium.
If you let the chip itself reorder instructions and fill the pipeline with ops that are ready-to-run (all inputs available), you get MUCH better performance (and can have effectively a VLIW backend). This is akin to what the current X64-64 chips from Intel and AMD do.

So, the failure of Itanium is reason enough to abandon an entire class of architectures? Existing VLIW architectures show the remarkable potential of static scheduling. The Mill is a newer example looking to extend this advantage to general purpose code. Out of order can help a bit, but at tremendous power and complexity, which translates into cost.

Chip marketing?

[mveloso]

How much of this is slowdown is marketing driven? There's no reason to release a chip that's 50% faster if people are buying plenty of the older chip. You want to spread that out over time.

Re:Chip marketing?

[Agripa]

How much of this is slowdown is marketing driven? There's no reason to release a chip that's 50% faster if people are buying plenty of the older chip. You want to spread that out over time.

Roughly none of it is market driven except for lack of infinite funds for capitol investment. If they could make a chip which is 50% faster for the same cost, then they would have released a lower power or cheaper chip of the same performance which is what they have done.

C++ == you already failed.

[Anonymous Coward]

Could aswell have chosen PHP, or JS, or another horrible monstrosity of a turd of a language.

Try again. E.g. with Haskell.
(Look up thread sparks. And stream fusion.)

Re:C++ == you already failed.

[Anonymous Coward]

I would have modded this up had you not posted anonymously - re Haskell

Re: C++ == you already failed.

[Anonymous Coward]

erlang?

Re:C++ == you already failed.

[SivDotnet]

Is "aswell" a word?

Re: C++ == you already failed.

[tigersha]

If Erlang does stream fusion I am the pope. The concurrency is good though.

mplayer does that just fine.

[Anonymous Coward]

Mplayer does streaming, and I have used it on the frame buffer console.

The art is to set the right config options in the command line, or preferably, the user's config file.
The best way to get those, with all the bells and whistles, is to use SMPlayer, configure it fully, then play a video, and open the mplayer logs (available via the menu). Copy out the command line, and paste whatever you need into your config file.
Then add the framebuffer playback target settings to it. Done.

Ran perfectly on my box. Although your framebuffer should not suck. Especially in terms of resolution and color space ... and render speed. It usually is the bottleneck, not mplayer.

If you want, you can even script a small keyboard interface to interact with its command pipe. I used LIRC via a LIRC Android app though, since I already had that setup for my home server's Internet radio with StreamRipper track keeper functionality.

Re:Idiot. We have enough stupid languages. RISC su

[WorBlux]

The re-order is fairly static/deterministic on x86 on the instruction stream level. Yes there's some dynamism to make up for cache misses and mis-predicts, but that's about 20% of the performance gain. However the re-order logic takes up a lot of die space and power in the critical pathway. Additionally x86 can't be a VLIW machine, it has a really hard time dispatching 4 ops/cycle, whereas static in-order machines can dispatch many more ops. The 32nm Itaniums could do 6-12 ops/cyle. The Mill is designed to sustain 33 ops/second at the high end of the familiy. Whether a compiler can actually find that in the code is a different question. Itanium was a decent architecture even if a commercial flop between delays, compiler problems, and x86_64. I think the Mill may get it's foot in the door not by competing head to head with Xeons in conventional servers, but by being lower power HPC, and be being well-matched for the micro-kernel space. Strong hardware memory and process isolation combined with 3 cycle function calls (including interupts, and calls across permission boundries.) could effectively solve the IPC penalty on mainstream processors.

Re:Idiot. We have enough stupid languages. RISC su

[Anonymous Coward]

Out of curiosity, what assembler instructions are you referring to? What stops them from being implemented as pseudo-instructions in the assembler, that are translated to 1 or 2 actual instructions? What stops anyone from writing short macros that are similar in functionality to the most complicated (and microcoded) VAX instructions?

And no, I'm not just making up hypotheticals. Macro-assemblers already exist, and RISC-V, to select an example I happen to know fairly well, supports more complicated operations by implementing them as pseudo-operations. For example, floating point instructions for absolute value, negation, etc. are supported by the RISC-V assembler, and they all are encoded as some variant of the floating-point sign inject instruction. I believe such instructions are not supported on most RISC architecture -- indeed, an instruction for negation of either fixed point or floating point numbers seems like the kind one might find on a CISC machine.

"We're at the end of the performance scaling..."

[Anonymous Coward]

Patterson is right.

That said, more hardware does not solve the real problem of bloated software, non-existent security, and the infestation of incompetent people in tech who should not be in tech at all.

I love the Mill

[mtaht]

If only I could get every slashdotter to take an hour out from flaming and look over the mill architecture diagram: http://millcomputing.com/wiki/... Or burn an hour grokking some part of it they might want to understand (ivan is a trip to watch) https://millcomputing.com/docs... It would be a better world. The Mill folk think way out of the box.

Re:I love the Mill

[Anonymous Coward]

I like the philosophy on their wiki description of it... but the latest news was 2015?

Who is using it - to do what??

Re:I love the Mill

[WorBlux]

It's not on hardware yet, they're still working on securing patents. Toolchain based on LLVM is almost alpha, and they may or may not have started putting it onto an FPGA. They still are active and giving a talk at a conference this week.

I say

[Anonymous Coward]

Itâ(TM)s time to implement the purge!

Gentoo

[ShoulderOfOrion]

Just give me more cores, so I can compile faster.

Re: Get working on it, trans womyn of color

[Anonymous Coward]

"haha, I never miss an opportunity to show if what a terrible person I am. I have no empathy, and think it's hilarious that other people get upset. Literally nobody actually likes me"

Thanks for sharing, but a therapist might be a better place

Huh...

[Anonymous Coward]

What's wrong with today's computer architecture, besides everyfuckingthing?

CSSProc

[tigersha]

We already have multi-architecture computing. Ever since MMX, SSE, 3dNow, AVX and all that back in the late 90s SIMD architecture has been on the map. And lots of computing is nowadays offloaded to GPUs. Most real CPU cycles are wasted waiting from stuff from a disk while updating some visual doodah on a screen. We probably need a doodah coprocessor that executes CSS animations directly in hardware.

What about maximising what you already have?

[CustomSolvers2]

This attitude of expecting absolute, immediate solutions for complex problems is one of the reasons why lots of things go wrong, not just with software/hardware but in general. Currently, there are a myriad of available alternatives to account for each single step of the process which are either far from optimal or being systematically misused.

Anyone interested in doing things properly at each single level (efficiency, security, scalability, etc.) has tons of available resources to do it under quite favourable conditions. But no matter how many resources you will have at your disposal, complex things will always require a relevant effort and doing things properly will always be more difficult than taking the easier path. If you focus on immediate goals and let irrelevant-from-the-technical-perspective concerns to affect important decisions, you would get a bad product and lots problems. And it will be your fault, your incompetence, your lack of understanding, your wrong decisions.

I am all for improving and further easing increasingly-complex tasks, but nothing of this should ever be seen as a magical solution. There is no magical solution anywhere. The ones knowing and working harder and caring about doing things properly (and being allowed to make relevant decisions on those fronts! This apparently-evident clarification doesn't seem too clear for quite a few people in the IT world) will get excellent results, everyone else will be, in the best scenario, conditioned by the circumstances, by pure chance.

Re:Idiot. We have enough stupid languages. RISC su

[Anonymous Coward]

Even 'RISC' processors aren't completely any longer either as almost every design have some specific complex ops that don't further decode, usually very specific functionality for Pete reasons... But yeah if you ignore the comparatively small number of such ops that don't further decode v. The majority that do, they're. All disc machines.

It's time

[Anonymous Coward]

For tacos!

Easy to say, hard to execute

[Tony Isaac]

It's easy to have an idea about wanting a "better" way to develop software. Many people go farther, actually creating new languages.

Haskell anyone? It's a functional language that's supposed to be superior to classics like C++. It's used by about 0.4% of programmers, according to Stack Overflow. How about Groovy, Scala, Kotlin?

What's hard is to get people on board, excited about your new programming idea.

Speed has more to do with effort than language

[Tony Isaac]

I recently wrote a program to compare DNA results, using C#. Basically, it has to compare two CSV files containing about a million rows of data, and spit out a list of matching rows.

On my first attempt, it took 37 seconds to match two files.
When I looked into what was taking the most time, it turned out to be my use of RegEx for parsing. Switching to good old Split() and x.Parse() functions brought the time down to 6 seconds.
Next, I found that File.ReadAllLines() was taking about 1.5 seconds per file. Switching to File.ReadAllBytes() took only 20 ms, bringing down the time per pair of files to about 2 seconds.
Next, I switched to parsing the fields character by character, using mainly switch() statements. In the end, I got the total time to match two files down to 160 ms.

No change of language was required, just tuning effort.

I suspect that this is true with much of our bloated software. It's slow, not because of the language, but because nobody does any real work to improve the performance of software.

Battery engineer

[ebvwfbw]

It's a great time to be a battery engineer. Just create a new battery that's 10 X better than what's out there.
Woo hoo! Now what else should we do?

Enter quantum computing

[Anonymous Coward]

Enter quantum computing

/. ignores original sources

[Anonymous Coward]

Who cares what the original source says. This is Slashdot---where facts are not tolerated very well.

Re:Idiot. We have enough stupid languages. RISC su

[WorBlux]

Also the lead designer of Itanium died before it was brought to market and the vision was compromised as a result.

Re:Moore's law is working more or less fine, thank

[Agripa]

Transistors are doubling every 24 months or so, on par with moore's original enunciation of the law, and slightly off the 18 months of his revision of said law.

He did not even say that and even Wikipedia gets it wrong with his original quote right there.

The complexity for minimum component costs has increased at a rate of roughly a factor of two per year.

It is about economics. For a given cost, the number of transistors doubles no matter whether that is due to increased density, increased area, or increased packaging. And this happens even if transistor performance is decreased which has happened several times.