3 ms·
1) I think this argument is plain wrong. It is incorrect that EVERY APP should use ALL CPUS. Rather, different apps use different cpus --> less interrupts -->
by countryqt30 10y ago
1) I think this argument is plain wrong. It is incorrect that EVERY APP should use ALL CPUS. Rather, different apps use different cpus --> less interrupts --> speed up.
2) I think they are actually very good at what can be done by now. How do you think they are so bad?
- valarauca1 10y ago1) Yes, but then you need to manage IO thread affinity, this isn't commonly done. Also you need to manage what is running on which NUMA node as often on 2 node systems 1 is almost never interrupted except for cross CPU conversation. Facebook moved to Single Socket Xeon-D's rather then bake task affinity to their HHVM run time. So yeah, people still screw this up a lot. 2) The main answer to concurrency these days is to just swap thread stacks in userland when ever something blocks. Yeah this works fine, but it's no different then what the kernel does for you. The stack is just smaller, the swapping is baked into the user land program. So you end up breaking most debuggers, and your C-FFI gets very slow. This isn't any faster then what the kernel is doing. It's just the language run-time limits stack size so the swapping happens faster. Setting smaller stack sizes and using Thread Groups yields similar performance.
- pjc50 10y agoMost people have a single, important foreground app which is the only one they care about latency of. The others are ticking over in the background, but because they don't have window focus the user doesn't care about their responsiveness so much.