Why has CPU frequency ceased to grow? (2014)

Post by pjmlp » Thu, Feb 22, 2018, 6:25 PM UTC

ta2384428 wrote: post #285

pjmlp wrote: post #278

Earlier quoted context omitted.

Yes they do, they are the building blocks for async/await, get a thread allocated from a thread pool when running, and you can control how the scheduling takes place, by providing your own scheduler implementation.

That is pretty cool, C++ has come a long way since I used it last about 15 years ago. It seems like both languages are equally capable here, with C++ having more power and foot guns when required as usual.

    task handle = create_task([] { /* ... */ });

    future handle = std::async(std::launch::async, [] { /* ... */ });

Post by deepnotderp » Thu, Feb 22, 2018, 9:00 PM UTC

Symmetry wrote: post #164

tedsanders wrote: post #48

Earlier quoted context omitted.

The 60 mV/dec limit applies to all materials, not just silicon. Beating it will require a fundamentally different type of operation. Agree that changes in materials will require massive investment and learning.

Sure, but many materials have much higher electron and hole mobility than silicon has.

Post by v_lisivka » Fri, Feb 23, 2018, 10:14 AM UTC

rcxdude wrote: post #74

v_lisivka wrote: post #64

Earlier quoted context omitted.

I.e. the problem is the state of processor, which need to be erased. So we can make stack of stateless processors, which will readily accept fresh data, because they will need to fill capacitors only, not discharge, and then discharged after use. Kind of multicore design, but with each core used for only 1/n of time at e.g. 1Thz frequency. Unlike parallel system, sequential calculation will work faster in such setup.

discharging and charging capacitance is generally pretty symmetric. I don't think what you're suggesting would provide much benefit.

Post by tagrun » Sat, Feb 24, 2018, 11:42 PM UTC

deepnotderp wrote: post #256

tagrun wrote: post #253

Earlier quoted context omitted.

That's just a plumbing problem which can be solved by lowering temperature or using a different material with lower resistivity. Yes, it'll probably cost more, but it's a problem that can readily be solved. But if your switching frequency is slow, it doesn't matter if you use a superconductor for wires. It is the switching frequency that truly determines the limits for gate times, which in turn determines how fast yo…

>That's just a plumbing problem which can be solved by lowering temperature or using a different material with lower resistivity. Yes, it'll probably cost more, but it's a problem that can readily be solved. No it's not. What is this magical material with ultra low resistance? And how do you plan to reduce capacitance? Btw, manufacturing terahertz speed transistors is very difficult. There are Mott FETs which will sw…

Post by romwell » Tue, Feb 27, 2018, 3:47 AM UTC

chrismorgan wrote: post #49

madez wrote: post #17

Earlier quoted context omitted.

While Rust doesn't promote a specific model for parallelism, it's stronger compiler helps a lot with that. https://doc.rust-lang.org/beta/nomicon/concurrency.html https://doc.rust-lang.org/book/second-edition/ch16-01-thread... I don't think fixing C(++) can give what Rust can give, because Rust has a clean start with these strong guarantees built-in while for C(++) it would always be an addon. Defaults are powerful.

A really powerful outworking of it is seen in the Rayon crate, where you can change a sequential iterator into a parallel iterator just by adding the crate, importing the trait and changing `iter` to `par_iter`. If it’s not thread-safe to do, then it won’t compile. (That’s the big difference from C++.) If it is, it will, and it’ll be smart about how it runs, spreading the load across all available cores pretty much o…