Hacker News Reader

Comment by dahart | Hacker News Reader

> I wish we could get back to working on getting FASTER cores rather than more of them. Some tasks just don't multi-thread.

Out of curiosity, are you working on tasks that don't parallelize? There are some for sure, but maybe more that do parallelize, just not trivially or easily? It seems like some people have wanted faster CPUs rather than more parallelism for as long as I can remember... decades. I'm wondering out loud if your wish has ever not been true.

I suspect we're stuck with getting more cores until there's a new fundamental breakthrough in physics. We're hitting the wall with CPU speeds, which is why GPUs have been seeing all the growth recently.

So I just went looking and found a CS term for hard to parallelize I hadn't heard before: P-complete. https://en.wikipedia.org/wiki/P-complete Are you working on stuff related to or dependent on any of these examples?

View on HN

I'm pretty sure OoO execution (which is how single threaded execution is improved in modern CPU cores) won't help with P- complete problems.

No not really. One of the biggest attractions of OoO is that it helps you find parallelism at the instruction level. So OoO as an architectural technique is one of the most helpful to problems hard to parallelize. The problem is there is a limited window of instructions where it can be applied. Trying to make one massive processor to find huge amounts of instruction level parallelism is just too hard.

Recently on here[0], Arm claimed for every 7% extra resources they put towards increasing the RoB they got 1% performance. Past a certain point it's not worth it. That was their justification for having half the window of rival Samsung chips.

[0] https://www.anandtech.com/show/12785/arm-cortex-a76-cpu-unve...

Yes, but if there's mathematically zero parallelism then OoO can't really help that much.

OpenSCAD could use some help

https://github.com/openscad/openscad/issues/391

Audio production. It is difficult if not impossible to parallelise one channel workload as each plugin depends on results of previous one.

If the plugins are chained together in a pipeline, that's actually trivial to parallelize: Each plugin runs on its own core/hyperthread, with small ring buffers between them to pass data along the pipeline.

But to process one plugin it still takes x amount of time and once cumulative x is longer than time of the audio buffer you'll get drop outs. That's why single core performance is the most important factor.

Ah, you mean realtime? Yeah, then your concerns are right.

What kind of workloads require more than ten thousand instructions per sample?

Splice type of synthesizer emulations, variants of convolution, physical modelling, filtering, oversampling and so on...

Synth emulation sounds like it can take a fractional-millisecond hit to run buffered on a different core. "variants of convolution" is hopelessly vague. Physical modeling can't be parallelized? Filtering I'm not an expert on but that's exactly where I'd expect a few instructions to go very far. Oversampling I already took into account when saying "ten thousand".

This is not to say that your problems aren't real. But I'm skeptical a concerted effort was ever made to go multi-core here.

What's an acceptable level of total latency, so I can understand better?

There are plugins that run their processing in parallel, but still they depend on results from the previous one in the chain. So there is only x number of plugins you can run in a channel, regardless how they process samples internally.

Acceptable latency would be between 2 to 25ms, but typically it is 5ms to work comfortable. My projects stutter on 25ms latency on Ryzen 1800x.

I completely blame the OS and/or software here, not the chip.

Let me put it this way:

Take a sample rate of 200kHz.

Take a pipeline with 12 steps that each require 2-3GHz.

These cores can easily synchronize to within a fraction of a microsecond, so round up to 1us.

Assume each plugin needs 10 samples available, and that the input-to-output latency might get as high as 20 samples when it's running on a completely dedicated core.

So put a buffer between each core of 20 samples, plus an extra 50% to be conservative, plus an extra 15us=3 samples to synchronize the cores with very conservative slop. So 33 samples per buffer.

12 inter-core buffers now take up a total of 396 samples, or slightly under 2ms. For a pipeline doing ~30GHz of work.

Nothing about modern multi-core CPU design makes a pipeline like this difficult. It's all software considerations, where the use of soft-realtime threads 'should' be straightforward, while letting the OS use the spare cores.

If you have a stutter at 25ms then someone blatantly screwed up their code.

Now do this for 32 (or more) audio tracks simultaneously.

You sound like you're disagreeing? If so I think you lost track of what this discussion was about.

I'm arguing that in audio processing, if the software is well-written, more cores can crush the performance of a single fast core. Even if it's a very serial pipeline.

Now you're here, describing an audio processing scenario where it's trivial to split the load up over many cores and run 10x faster or more.

I agree, more cores are better...?

If you're just arguing that you can't dedicate 12 cores per track while also having 32 tracks... that's certainly true, but completely irrelevant? Completely accurate that the multi-core CPU is not 300 times faster than a single fast core. But nobody said it was.

More cores are better, but you are limited by the slowest chain. So you can have 100 of cores, but if only one chain can't be computed for time duration of the buffer it will stutter. It is not uncommon to have like %15 utilisation on 16+ core cpu and having it stutter, because all cores are too slow to process the chain on time.

Reply on news.ycombinator.com