That's still wrong: scheduling and synchronisation take time, especially synchronization, which has both an overhead and introduces uncertainty in when the lock will be released. As I said, multi-threading results in worse per core performance, and depending on your data it might actually even perform worse on multiple cores (sometimes; most often it offers a moderate speed-up, not what you'd expect).
You also presented the threadedness as a cure-all solution to performance problems, which it is not. That's wrong.
You also never implied that you mean paralelism in general as opposed to just threads. But yeah, in the case you can't use any kind of parallelism, you're kind of screwed. The problem is that threads are one of the worst ways of introducing parallelism.
> That's still wrong: scheduling and synchronisation take time, especially synchronization, which has both an overhead and introduces uncertainty in when the lock will be released.
No matter your method, you need some kind of scheduling and synchronization if you want to go beyond 5 billion CPU cycles per second on a multi-user site.
> You also presented the threadedness as a cure-all solution to performance problems, which it is not. That's wrong.
No I didn't. But having more than one core in use is the only way to get over a certain threshold, no matter how good your code is.
> The problem is that threads are one of the worst ways of introducing parallelism.
Like I said, it would have been better if I was clearer that I mean completely non-parallel code. But parallelism was my point. Everything you're saying about threads in a single process vs. multiple processes is not me being wrong, because it wasn't my argument.
Or to put it another way: Yes threads in a single process are on the bad end of parallelism. But they're also the easiest. If you see a statement that code can't even do that, then that should already imply that you can't run multiple processes on the same website instance.
Ok, let's chalk it up as a miscommunication for the most part, I'm sorry for calling your comment "very wrong". We can agree that it was incomplete/imprecise, right? It got explained, so let's move on :) But, I take issue with one more bit here:
> But they're also the easiest.
I don't believe that's true. Threads are the easiest to work with if you have a lot of shared, mutable state kept within an adress space of a single process and, crucially, cannot do anything about it. I don't know if that's the case for HN backend, but it rarely is in practice. Then there's a problem of multiple different threading implementations out there, and also an issue of how the threading mechanisms interact with the runtime (Python is multithreaded, but has a GIL). Frankly, it's a minefield on all sides, and implementing a system that is multithreaded, performant, and correct at the same time is the exact opposite of what I'd call "easy". That's also the reason why I disagree here:
> If you see a statement that code can't even do that, then that should already imply that you can't run multiple processes
To me, threads are not the first thing that comes to mind when I think about parallelism. Being unable to leverage threads, to me, is a good thing: just let this sleeping can of worms lie. As you know, there are multiple (many) ways of achieving parallelism, and they differ very much: I don't think being unable to leverage one of them says anything about the ability to use any of the others. That may be just me, though, so let's just say I have a different impression here and call it a day :)
Sure, very little to disagree with, and moving on is fine, but I do want to make one small note: the reason I say threads are easier is that in almost every case you can take a multi-process model and turn it into an efficient multi-thread model with minimal effort. Threads give you more tools, and a lot of those tools are slow. And if a type of parallelism won't work with threads, it very likely won't work with anything else.
You also presented the threadedness as a cure-all solution to performance problems, which it is not. That's wrong.
You also never implied that you mean paralelism in general as opposed to just threads. But yeah, in the case you can't use any kind of parallelism, you're kind of screwed. The problem is that threads are one of the worst ways of introducing parallelism.