Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

For those who have not looked yet: John Hennessey presentation. Argues -- with a lot of detail -- that Moore's law has closed out, that energy efficiency is the next key metric, and that specialized hardware (like TPU) might be the future.

When I buy a machine, I am now perfectly happy buying an old CPU, and I think this shows you why. You can buy something from as far back as 2012, and you're okay.

However, I do look for fast memory. SSDs at least, and I wish he had added a slide about the drop in memory speed. Am I at inflection?

Perhaps the future is: you buy an old laptop with specs like today and then you buy one additional piece of hardware (TPU, ASIC, Graphics for gaming etc).



(for the average user) the CPU speed isn't relevant anymore, even the number of cores. Internet speed plays the biggest factor when watching a movie, opening a web page, using some cloud-based app. Then memory speed and GPU speed (even in cell phones) come second: how fast will your CPU grab that data and process something.

In niches, of course, CPU speed matters. I want to compile something in half of the time. I want to train my AI model faster. But what really bugs me is when I have to wait for a refresh on some site, this really makes me loose focus (and then I come to HN to see some news and time goes by).


>CPU speed isn't relevant anymore

Only because most software is conceptually stuck in the 50s and Intel fell asleep at the wheel. Having extra cores can allow you to move away from cludgy and insanely complicated solutions to much simpler code. In turn, this enables faster development and experimentation.


Generally code becomes more complicated when you have to run it on multiple cores.

I personally am working on a toy actor library to test if easy but still reasonably efficient parallelization is possible even with heavy communication needs. I see a 2.3x slowdown when I run it on a single core vs the baseline that uses locks but it reaches parity at higher levels of parallelism and congestion when you have 10 million actors each 32 bytes in size running on 4 threads.

As soon as you need to acquire two locks that are only known at runtime it starts to become increasingly difficult to find a solution. It will usually be highly specific to the problem at hand and not generalize at all when the problem changes slightly.

If you limit yourself to only acquiring one lock at a time then generalizing becomes simpler but you now have to implement something very similar to transaction rollback. It isn't the end of the world and it is definitively possible but compared to not worrying about it at all in single threaded code it's a massive headache.


Some of the most drastic simplifications I've made to real-life code in the recent years were achieved by splitting a "classic" program into multiple independent agents. Making things "parallel" wasn't even the goal. The goal was to clean up some messes.

>As soon as you need to acquire two locks that are only known at runtime

Why would you need to acquire two locks that are only known at runtime when using the actor model?


I'm an average computer user. I like to watch videos and game on weekends. For me CPU speed remains a massive bottleneck. I like to play Kerbal Space Program and, with realism mods, it really needs general computing horsepower.

That said, moore's law is irrelevant. I don't care about transistor density, or even CPU count. I care about processing power. Give me a 4-slot motherboard to mount for AMD threadrippers ... I would consider that as an option. What matters to me is price.


Hi! 4-slot motherboard for AMD? That's something the "average user" wouldn't even know where to begin.

I understand your poing, but when I think of "average user", I mean users who wouldn't dare to open a case, and wouldn't even know where is the CPU and why there are so many coolers inside.


>energy efficiency is the next key metric, and that specialized hardware (like TPU) might be the future.

This is nonsense pushed forward by large corporations who want to own all your data and computational capacity.


Admittedly knowing little about how multi-core CPUs work, I've always thought the next breakthrough in CPU tech would be a hardware-based scheduler, a chip that effectively load balances threads to ensure all cores are used equally and simplifies the writing of software. The dev writes thread-safe code and the hardware does the rest. I wonder how feasible that really is.


That sounds perfectly reasonable to me, but John Hennessy literally wrote the book on computer architecture. Towards the end of the deck he has a slide that we shouldn't expect large gains from improved architecture (on general purpose chips) in the future. I'm inclined to believe him, although I would be interested in hearing a deeper proof/disproof of the architecture you proposed.


This is essentially what hyper-threading in modern processors is attempting to do.


No, it's not?

Point one: Indeed, untold millions of dollars can be saved by improving data center efficiency. But if the processors are in desktops instead, where the price pain isn't actually enough to drive improvements in efficiency, then we as a society just pay a higher power bill... Furthermore, data center power tends to be greener than general purpose city grids.

Point two: they could have as easily said GPUs to avoid the fear of data centre only proprietary lock in... The point is the same: we seem to have hit the point where specialized linear algebra coprocessors make a huge difference.


>price pain isn't actually enough to drive improvements in efficiency

You have something reversed here.

Hardware companies that make consumer devices are pumping barrels of money in improving CPU power usage to enable longer battery life on mobile devices.

Google, on the other hand, promotes insanely power-hungry neural nets as the future of computing, because that's the kind of future that gives them the deciding edge in the market.


Energy efficiency (performance/watt) is the key metric because servers are limited by cooling/power dissipation and mobile is limited by battery capacity.

His chart shows TPU with ~80x the performance/watt of a CPU, indicating the potential advantages of domain-specific architectures over general purpose for specific applications.

None of this should be surprising to anyone who uses a GPU.


> "that energy efficiency is the next key metric"

What limits cpu speed? => https://electronics.stackexchange.com/questions/122050/what-...

More efficiency means more overclocking. Also, better cooling/dissipation methods and less gate delay.

We may be hitting the limits of wire thinness, but I get a strong feeling (ie not an expert) we've got a decent ways to go before we hit the limits of clock speed.


I'm not an expert either, but from what I do recall of my EE courses in college...

Circuits with respect to frequency, past a given point capacitance starts to look like an inductor at high frequencies. The charge and discharge sloshing happens fast enough that power really gets wasted to heat or other leaks (but mostly heat for the things we build).

My personal gut-feeling is that faster Hz probably isn't happening without some kind of radically different / exotic design or process. Further that is the case it's unlikely to scale down. That kind of system might be useful for AIs, large governments/corporations, and maybe game consoles that need a lot of power and are wall-powered so they don't care.


That's... extremely not what's limiting clock speed. For one, at this regime the resistance tends to swamp out the inductance.


It absolutely is; performance is mostly limited by power usage and dissipation, and the above is describing why at faster frequencies more power is used.


Power dissipation isn't coming from wires looking like inductors...


My i7-2600k @ 4.4GHz agrees with you. The only reason I would upgrade would be for better USB 3+ support (I have a hard time with anything more complex than a SuperSpeed flash drive).

SSDs are by far the most cost-effective upgrade you can get nowadays. HDDs tend to be the bottleneck for boot times and general "snappiness" nowadays.


The reason I would upgrade from there is PCIe 3.0+, and thus support for fast NVME cards. They are almost as much a step up again from SATA SSD, as SATA SSD was from spinning rust IMHO

IIRC the sandy bridge generation could only do PCIe 2.0.


Very true, I did just recently pass up a great deal on an NVMe drive because I can't use it in my current setup. I believe PCIe 2.0 will also bottleneck USB 3.2 (or Gen 2x2 or whatever the naming scheme is now), and whatever GPU I upgrade to next (I read that it's a bottleneck with the GTX 1080 and up)

NVMe is the only thing that will cause a noticeable improvement for me though, seeing as I still game on a 1080p60 monitor and generally don't need that sort of speed from any USB peripheral.

Still, the processor itself kicks ass and I think the only reason why most people would need to upgrade are for newer peripherals.


i seem to recall something about some carbon technology recently that is supposedly the next big revolution in semiconductors, and might revive Moore's Law? I wanna say it was about how carbon nanotubes can be used as an excellent semiconductoer, and because their width is at the atomic scale, they can result in even smaller transistors.

or something to that effect. Not sure where I read it tho. Maybe on here


There was a thing here recently about carbon nanotube transistors. I also watched a video on youtube where they showed briefly how it works, it was very interesting. Essentially very very very small mechanical switches!


>Perhaps the future is: you buy an old laptop with specs like today and then you buy one additional piece of hardware (TPU, ASIC, Graphics for gaming etc).

If Google has its way, the future will be: you buy a Chromebook and do all the real work on Google Cloud. Note that John Hennessy is a chair of Alphabet. And in case someone here forgot, TPUs were developed by Google and so was Tensorflow.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: