On Thu, Dec 22, 2011 at 08:05:08AM +0100, Hongli Lai <hon...@phusion.nl> wrote:
> >> Are you talking about hardware simultaneous multithreading
> >> (http://en.wikipedia.org/wiki/Simultaneous_multithreading), e.g.
> >> HyperThreading?
> >
> > No, just distant history, try
> > http://en.wikipedia.org/wiki/Thread_%28computer_science%29 if you like
> > wikipedia:
>
> According to that same Wikipedia article, some CPUs have multiple
> register files in order to reduce thread switching time, i.e. what you
> describe as extra support for multiple contexts. According to the
> article, that idea came in the late 1990s to x86 desktop CPUs when
> Intel introduced HyperThreading. So it looks like we're talking about
> the same thing.
No, hyperthreading is something completely else - what I am talking about is
hardware support for multiple process contexts.
For example, you could tag tlb entries with a "process id" kind of thing and
tell the cpu to only use tlb entries matching the current id, avoiding tlb
flushes.
Haven't seen this in any x86 cpu, but I am not an expert. Of the top of
the hat, I think some sparc cpus have that though.
> > Thats not all I am saying, but I would say that for these programs, yes.
>
> I agree that threads tend to be overhyped compared to processes, but
> I'm here to learn the truth, which is why I'm asking these things.
I'll give you truth, from my side only, though :)
> It's true that the second program adds an extra layer of indirection
> (the 'data' variable). However:
> 1. If the data is accessed frequently then both the pointer and the
> ThreadData that it points to should be cached by the CPU cache, making
> the indirection very cheap.
I guess we will have to disagree on the "cheap" thing. For perl for
example this indirection costs between 30 and 200% in typical programs,
which to me is not "cheap", but I can see how people can call it "cheap".
> 2. Suppose the system has two cores and N = 4, so two processes or two
> threads will be scheduled on a single core. A context switch to
> another thread on the same core should be cheaper because 1) the MMU
> register does not have to swapped and 2) no existing TLB entries have
> to be invalidated.
>
> I think that (1) and (2) are sufficiently beneficial that the program
> should run faster overall, even with the extra indirection. Do you not
> think so?
(1) is not beneficial at all for speed, even you admit that it's merely
"cheap", but it's not free of costs, so it's the opposite of beneficial, it's
detrimental
(2) is not beneficial either, because you use a suboptimal model already,
namely using kernel threads (or processed) where user-level threads do.
For example, my Coro thread package does about 2 mio context switches in
userspace, and about 200k when kernel threads are used.
Of course threads are beneficial for many applications, but running
computations in a time-sliced multitasking way on a single core is not one
of them. Making efficient use of memory bandwidth and cpu registers is
also not one of them.
However, if your threads mainly do blocking operations (involving context
switches) then the context switches are "free". This is why I don't think
libeio is the wrong approach.
In fact, it was long believed that true AIO is good for a os to have, but
most kernels that do aio use threads internally, simply because they have a
highly optimised process/thread management already.
Even if you design your os to be async from ground up, you still suffer from
a lot of overhead in upcalls and similar mechanisms.
So while "true" aio might be better, I suspect that using threads to do I/O
is actually the thing they were designed for, and are most efficient at.
In these cases it makes sense to have more than one thread per core (and
I wished the linux scheduler wouldn't be so bad and keep related threads
together - as it is, linux often schedules libeios threads on another cpu,
creating a lot of memory traffic resulting in very measurable slowdowns).
--
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
