141–150 of 301 posts
I took a class that went over this in depth like 3-4 years ago. Basically the message was that serial performance is saturating, and the only way to get speed improvements in the future is going to be by exploiting parallelism. However, most programmers, and programming languages, remain stuck in a serial-by-default paradigm. I'm surprised that there hasn't emerged a "parallel-by-default C++" kind of language + hardw…
DARPA manufactured a THz transistor made of InP back in 2014.
Silicon isn't the only semiconductor in nature, and others are actively being researched.
Also, "when you increase the frequency you increase the power" (which is their argument) doesn't explain why they can't increase the frequencies. That was always the case even back in 1960s.
What they actually need to explain is why they can't make the silicon more power-efficient anymore; all toy-physics arguments (such approximations/linearizations work only for a very limited range of frequencies, if they do at all, anyway meaning their scaling-relations aren't universal like they're trying to portray and those coefficients they ignore aren't constant across voltage, frequency, materials, ... either; you almost never get such simple and universal answers in condensed matter physics even for much simpler problems) mentioned there could have been made 50 years ago as well, but silicon CPU frequencies did go up.
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.
Doesn't go also make it relatively easy to write parallel code?
Go's implementation of these things is nice, neat, and all included out of the box though which is nice.
In general you can make parallelism easy, or efficient, rarely both, at least not in a way that can solve problems generally.
edit: I should add Go does also come with a data-race detection tool which can be very useful. Not sure any other language includes that out of the box!
I took a class that went over this in depth like 3-4 years ago. Basically the message was that serial performance is saturating, and the only way to get speed improvements in the future is going to be by exploiting parallelism. However, most programmers, and programming languages, remain stuck in a serial-by-default paradigm. I'm surprised that there hasn't emerged a "parallel-by-default C++" kind of language + hardw…
there has and it's called labview, although by hardware you may have meant processors. labview has many quirks, but it surprisingly gets many things right, even in futuristic ways. when i move back to text-based languages it's always a jolt primarily due to the serial nature of them, even those that support asynchronous computation. it's really hard to recalibrate to having to assign things to temporary variables and the like. and the lower dimensions of a text file compared to a higher dimensional canvas is something that sticks out as a limiting factor in supporting parallel by default.
> I find the apparent stagnation extremely depressing.
agreed.
Using a proper thermal interface material in their CPUs would be a start...
When you can decrease the temps of Intel CPUs by 20°C with delidding, the heat argument seems quite constructed.
I took a class that went over this in depth like 3-4 years ago. Basically the message was that serial performance is saturating, and the only way to get speed improvements in the future is going to be by exploiting parallelism. However, most programmers, and programming languages, remain stuck in a serial-by-default paradigm. I'm surprised that there hasn't emerged a "parallel-by-default C++" kind of language + hardw…
Earlier quoted context omitted.
Still, if you have only two floats to add and make a decision based on the result, a GPU or a TPU will not help you. Hashing, maybe sorting, blitting and some math could be performed at the on-module DRAM controller level even, without data crossing over the slow DDR4 bus or mangling the CPU caches. I'd love, in fact, to explore such an architecture in a simulator. What would happen to CPU performance if, say, hashes…
> memory be cleared without zeroes In some specific cases, such as when the Linux kernel maps memory into your process, this is exactly what happens. When you write the page, it faults and clears it on demand; but I don't think there would be a considerable benefit to doing this at a finer granularity.
I took a class that went over this in depth like 3-4 years ago. Basically the message was that serial performance is saturating, and the only way to get speed improvements in the future is going to be by exploiting parallelism. However, most programmers, and programming languages, remain stuck in a serial-by-default paradigm. I'm surprised that there hasn't emerged a "parallel-by-default C++" kind of language + hardw…
For example, for web programming, you can throw several machines (or processes) of your serial program to have it run in parallel for all practical purpose.
I took a class that went over this in depth like 3-4 years ago. Basically the message was that serial performance is saturating, and the only way to get speed improvements in the future is going to be by exploiting parallelism. However, most programmers, and programming languages, remain stuck in a serial-by-default paradigm. I'm surprised that there hasn't emerged a "parallel-by-default C++" kind of language + hardw…
CUDA. OpenCL. Vulkan Compute Shaders. DirectCompute. C++ AMP. AMD's ROCm. Intel's SPMD. Khronos SYCL.
I took a class that went over this in depth like 3-4 years ago. Basically the message was that serial performance is saturating, and the only way to get speed improvements in the future is going to be by exploiting parallelism. However, most programmers, and programming languages, remain stuck in a serial-by-default paradigm. I'm surprised that there hasn't emerged a "parallel-by-default C++" kind of language + hardw…