Hacker News Reader

Comment by mgaunard | Hacker News Reader

Whenever I see someone arguing their code is better because it's multithreaded, I cringe.

Most developers cannot do multithreading correctly, and unless you're particularly good about it it's just going to introduce not only lots of bugs but also performance problems.

The only folks in that space that seem to do it well are ScyllaDB.

View on HN

Multi-threading easy is it's hard synchronization that's

Multi-threading is easy it's synchronization that's hard.

I see there what did you.

Oh, now I got it!

I have been writing multithreaded code for decades and it is hard. My current database engine can break a single query into tasks to be run in parallel for much faster performance; but finding and fixing bugs is a real challenge.

All it takes is one critical section to not be protected (i.e. locked) to cause a bug. A series of tests can run hundreds of times correctly without detecting the problem. It is only when a context switch happens at a certain microsecond that the error is exposed.

I am a true believer in multithreading as my own code can see tremendous performance gains using it on the latest multi-core CPUs; but tread very carefully when programming in this manner.

ScyllaDB doesn't do multithreading. It has 1 thread per core.

That's the good way to do it.

And sorry, but that is multithreading, there are several cores.

Yep, multiple C++ threads each of which is allocated to a single core.

That's not true. Scylla does multi-threading. Scylla is a single process, single address space. It does pin the threads to individual hyper threads but there are additional other workers in the background as well.

The hot path is message-passing.

Native multi-threading is used when you have functionality that already works on threads and you don't want to port it.

Multi-thread is not used in the hot path.

A single data-part/shard is served by a single thread.

not do dismiss anything or what..

but how does this kind of multithreading (one thread per core) is better than proper multithreading (many threads per core)?

Perhaps you’re thinking about SMT (e.g. Intel Hyper Threading) when you say “proper multithreading”?

I’m not sure it’s valid to say that only SMT is “proper multithreading”, especially since multithreading as a concept predates it by quite a way.

SMT has a quite a few performance issues since resources such as the L1, L2, and branch predictor are shared between the threads, which can lead to contention that hurts the performance of all the SMT threads sharing a physical core.

SMP is no less “proper”, and as core counts have increased significantly on commodity CPUs, the use of spinning threads bound to a single core each has become a common paradigm.

Oversubscription without SMT (i.e. many threads per core) is possible, but unless you have a workload where each thread is I/O bound with a substantial amount of time spent blocking, the overhead of scheduling and context switching means throughput will likely decrease.

All SMT does is allow multiple instruction counters on the same superscalar core. It increases utilization of all compute units and therefore increases throughput.

Of course it increases latency, since those resources are not fully exclusive to a particular thread anymore.

Whether or not it's a good thing depends on what you care about. You could also argue that a good program would be able to saturate a single superscalar core with a single thread and thus wouldn't benefit from SMT at all, but I think that would be hard to guarantee in practice.

I don’t disagree, I’m just trying to unpack what the GP might have meant by “proper multithreading”.

Doing multiple threads per core is not "proper multithreading", since it's a well-known antipattern.

..it's not good because it's bad?

Why is it an anti pattern, this is news to me?

More threads on a single core equal more context switches, which reduces the effective amount of instructions you can process.

Well sure, but why would that make it "improper multithreading"? Is polymorphism based on vtables not "proper OOP"? We rely on many abstractions that aren't free in terms of CPU cycles because it makes development easier or less error prone.

And setting up, say, one thread per HTTP request will likely be negligible because blocking I/O is where time is spent anyways..

It's not improper it's just non-optimal.

And we have had non-blocking I/O for quite some time now.

Any networking program doing blocking I/O is doing it wrong.

Your I/O should only be done synchronously if it's non-blocking.

Now for disk I/O, it's a more muddy thing, it's actually quite different from networking since it's more transparently managed by the operating system.

Kernel threads do not scale, and neither does the scheduler.

Userland threads (or fibers, or stackful coroutines) do scale better though.

My limited understanding is that there's less cache thrashing (from multiple different workloads scheduled on the same core) and less scheduler overhead (from less overall threads).

Just to add that scheduling overhead goes away with SMT (assuming you don’t oversubscribe), but the sharing of caches and branch prediction logic is still an issue as you point out.

Reply on news.ycombinator.com