14
$\begingroup$

Are there any changes that could be made to CPUs to make them perform better for concurrent runtimes like Rust? For instance, are there changes to branch prediction implementations or cache sizes that would help concurrent runtimes?

I have the impression that current CPU designs might be optimized more for procedural runtimes like C. If we were instead going to optimize for concurrent runtimes, how would CPUs look different?

For isntance, branch prediction was implemented based on generalizations drawn in research papers analyzing procedural codes. I'm wondering if the concurrency abstraction will add a significant working-set to the runtime that adversely impacts existing branch prediction algorithms. For example, predicting in a for loop is one thing, but when the target of the branch is always some new portion of memory (graphic, text, etc), it'll always be a cache miss, and there'll never be branch history for it-- because neither have touched it yet.

This is probably a silly question because the content, though it might always be in RAM, will be branched to an order-of-magnitude less than it'll be used (once it's been loaded to cache)...but still, there should be an observable temporal-boundary to the contexts stored in the cache and branch predictors in a procedural runtime, that would be manifest as an abstraction-boundary in a more parallelized environment. So I'm wondering... Have these boundaries been observed? Have any research papers have analyzed this?

Are CPU architectures biased towards procedural code over concurrent code; or are modern CPUs sufficiently general-purpose that a highly concurrent language doesn't suffer?

Improve this question
$\endgroup$
10
  • 2
    $\begingroup$ Have you looked at literature around the Itanium (IA-64) architecture? It was designed with grand dreams of ultraparallelism, but then people failed to make compilers that would take advantage of the CPU's features, and software didn't perform so well after all. $\endgroup$
    – Gilles 'SO- stop being evil'
    Sep 9, 2015 at 19:49
  • $\begingroup$ @Gilles yes. Although a different question, that's actually an interesting observation-- perhaps the parallelism baked into Itanium would be better suited to modern concurrent languages? $\endgroup$
    – paIncrease
    Sep 9, 2015 at 20:23
  • $\begingroup$ @Gilles: And similarly, the new Mill architecture seems to have been built with parallelism and low-cost switches in mind. For example, by using a single virtual address space for all "processes", it pushes back the TLB between the last cache level and the device controllers (see slide 49 of millcomputing.com/docs/memory). $\endgroup$
    – Matthieu M.
    Sep 10, 2015 at 11:52
  • 1
    $\begingroup$ @pedAntic Rust needing a runtime is a misconception that's easy to make: chat.stackoverflow.com/transcript/message/24171983#24171983. Your question seems to support this misconception which isn't a good thing for Rust. $\endgroup$
    – ArtemGr
    Sep 11, 2015 at 17:50
  • 1
    $\begingroup$ @pedAntic You see, Rust had a concurrent runtime (for green threading), but it doesn't anymore. Right now Rust is largely in the same league as C in regards to concurrency performance profile. The only difference from C is that the static analysis in Rust makes the concurrency mostly safe. $\endgroup$
    – ArtemGr
    Sep 11, 2015 at 18:03

2 Answers 2

Reset to default
1
$\begingroup$

It is probably more the case that modern computer architectures are designed with the goal of improving the quality of code generated by compilers against a budget of cost in die area and power used. Runtime libraries are just a specific instance of compiled code that needs to be executed in an efficient manner.

For a very long time, the target language for most architectures has been the "C" language. This reflects the modest demands that that language makes on its hardware and the fact that it has become an almost universal systems programming language (Sorry Rust and Go, you have a long way to go to beat C).

A consequence of this seems to be that new languages are often defined in terms of their C equivalent semantics just so that they will avoid needing processor facilities that are likely to be absent on current computers.

The payoff for a processor that matches well with modern compilers is that code from those compilers runs well and the processor has at least a chance to be competitive. The cost of failure here dooms the processor before it can get started. Just two examples in the negative include the iAPX-432 and the Itanium, both by Intel. Both had a very poor relationship with their compilers (Ada and C respectively) with the failure of the products turning into a blame game between silicon and software.

Improve this answer
$\endgroup$
0
$\begingroup$

Without a doubt, yes.

In particular, the communications model implied by C99 is shared-memory. More advanced concurrent languages have richer communication models, such as message passing channels (as in Rust).

Modern CPU architectures do have explicit hardware support for shared-memory. In particular, cache coherency protocols like MESI are implemented in actual gates and wires. There is no real support for message passing between processes, even though the idea of message passing isn't alien to CPU's. Modern PCI-e buses even emulate shared memory using message passing, whereas CPU processes have to emulate message passing using shared memory!

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.