On Tue, Mar 16, 2010 at 06:55:07AM +0000, James Mansion
<ja...@mansionfamily.plus.com> wrote:
> Marc Lehmann wrote:
>> The precise problem they were designed to solve is slow context switching
>> times due to reloading of cpu registers.
>>
> You have to reload the registers when you context switch between threads
> *or* processes. Its
> the VM and security context switch that hurt.
And those are stored in... *surprise* registers.
You have proven multiple times that you have no clue about the topics you
try to lecture about. Even wikipedia would help at this point.
People have *explained* this very point to you (not just me), it is high time
for you to actually read and understand.
Then maybe you can argue.
>> With threads, often you are when you want performance - the
>> synchronisation between cpus when using threads can be very costly, and is
>> usually unnecessary (why not use the extra hardware you got?).
>>
> And the synchronisation when sharing data between proceses is cheaper in
> what way?
Yes, because you don't share memory, files, most data structures, don'tr
need locking in most cases etc. etc.
>> Threads force memory/cpu state synchronisation among multiple cores (when
>> they actually run on multiple cores), which often requires cache flushes, tlb
>> flushes, synchronous IPIs and so on.
>>
> And so does sharing state between processes. The amount of sharing is
> the key thing.
Exactly...
> The heap is shared and that can be good, or bad, depending on what you
> need and how you use it.
The point is that threads force sharing of everything, even the non-needed
parts, which is *always* bad because you never need it.
The effetc might be negligible, but it is never good.
>> Processes were designed for parallel processing - they don't force these
>> kinds of synchronisation between cpus, and naturally scale even over host
>> boundaries, making them both more efficient and more scalable in general.
>>
> Only when the state that is shared is minimal.
It's always much less than with threads - memory management is always
forcing this, as are fd operations, file operations etc., because each
time the kernel has to lock or, even worse, IPI.
Your argument is wrong because you get the effects even when the shared
state is not "minimal".
>> That of course is a limitation in those APIs - you don't argue that
>> threads are more efficient in general because some APIs force you to use
>> them? That wouldn't make sense.
>>
> Oh great, I'll just forget about my database then.
Yeah, maybe... both mysql and postgresql don't suffer from these problems.
> And libmemcached. And
neither does memcached...
> doing any crypto
Crypto APIs don't usually block, they use CPU.
> or signature stuff. No monte-carlo or XSLT for me. I'd better not read
> from disk, and
> as for NFS ...
Yes, reading from disk and NFS is generally a bad idea. Note that threads
are *very* good uses for these kind of applications, and I always
recommend doing those with threads - there is no parallel processing
involved.
Note also, however, that these kind of apps work much faster on GNU/Linux
when you pin all your threads on a single CPU (-core). You can benchmark
these things, and the reason is task switching time and inter-processor
communication overhead.
The effects are so large you can easily see them from perl using IO::AIO
on a measly Q6600. Heck, even eventfdis almost twice as fast on the same
core as between cores.
Unfortunately, there is no API to configure those things (not even in
GNU/Linux, afaics, although you can at least pin threads to specific
cores).
> Yes, I am arguing that threads are *more practical* and something that
Yes, me too. Especially when confined to a single core, where they can be
really useful e.g. for AIO.
>> You keep repeating it, but it doesn't make it true :-) Processes spread
>> their load evenly over cpus, threads cannot by design.
>>
> I must have completely imagined it then. Those auto-parallelising
> compilers are just
> smoke and mirrors too.
Yes, because they tend to not work well in the general case, which is
exactly what I am saying.
Stop building strawmen and shooting them down, try to argue what we
*really* say.
>> Keep in mind that if a malloc or a free often result in costly IPIs,
>> copying between CPUs and so on.
>>
> You think accessing disparate bits of memory that are not actively
> contended slows
> everything?
No, I think what I wrote, not your strawman.
> Have you looked at the thread-aware allocators? Or perhaps
They help how?
> using
> splintered (and possibly thread local) object pools?
They help with the problem how?
I don't think you even remote understand the issues causing IPIs.
>> Also keep in mind that threads share all memory by default, even when it
>> makes little sense, performance-wise.
>>
> Yes, I know.
How surprising. That's good!
>> Counterexamples disprove the general case how?
> Overgeneralisation is easy to disprove.
I think I have done that, yes. Keep in mind that you are the only one
overgeneralising, I never claimed, as you did, that threads don't have
their uses.
But as always, you *have* to know what you are doing. Your claim that
threads are perfect for everything and especially multiple cores is just
wrong, it doesn't reflect reality.
And it is clear by now that you really don't know any of the actual issues
that exist in *real* systems.
>> The fact that you a) don't even know the very basics of threads b) didn't
>> bother to read my e-mail and c) think you need to behave like an asshole
>>
> I think I do, but others can judge, and they can see how you behave to
Yeah, they can :)
> people who disagree with you in the archives.
At least I do so with arguments and knowledge and not by starting to
insult people because I have no other arguments - one would hope you would
start to do the same. Building strawman and shooting them down is just
stupid, and if you do it out of ignorance, it's poor.
Anyways, it is now clear that you have personal issues with me, which
explains your behaviour.
Maybe you should learn how to separate personal issues from facts and
arguments.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
