Hah! Avoid thread programming!
mutex locking time is... *heh* around 26000 microseconds... Longer than poll() Go figure. And you can't do interthread communication without -some- form of locking, be it kernel or userspace. (socket I/O locking is handled in the kernel) Anyways, for future reference : streams are faster than messages. Unless you have a -really- speedy lock-aquisition system... How does this apply to GGI? Easy. Don't do lock-aquisition in commands/etc unless you -have- to. Regardless of how thread-friendly you want it. Graphics programming isn't particularily multithread friendly anyways. You don't really want to have multiple command-streams to most videocards and even worse, mixing rendering with accels can be fatal on some. Now on the flip side, it'd be very handy to have a libGGIthreads library or something to give one a threaded interface to -all- of GGI. Sorry, just playing with massively threaded proggies finding delays :) G'day, eh? :) - Teunis incidentally, mandrake 6.0 + upgraded kernel + compiler
Re: Hah! Avoid thread programming!
teunis wrote: mutex locking time is... *heh* around 26000 microseconds... Longer than poll() Go figure. So much ? Well, it must be implemented via a system call then... Well, with threads managed by the kernel it is not so astonishing, but you can surely do much better if you only want to lock in-memory data structures... Which library do you use for threads/mutexes, linuxthread ? POSIX ? Oh. by the way, while I'm thinking, how did you do your benchmark ? An empty lock/unlock I guess ? Not by two threads on a uniprocessor I hope (this environment implies a scheduling so... here is your implicit system call) Well, anyway, I'd be interested in seing your benchmark if it's a simple test programs. So much time for locking seems astounding to me. (With Chorus on a 386 in 1994, it was much faster...) Now on the flip side, it'd be very handy to have a libGGIthreads library or something to give one a threaded interface to -all- of GGI. Hmmm. With additional delays, I don't know if it would be worth the work (especially as everyone would try to use for hype and then go back complaining about the performance)... Nevertheless, your application is very interesting with respect to this issue of real-graphic-world MT programming ! Rodolphe
Re: Hah! Avoid thread programming!
On Fri, 28 Jan 2000, Rodolphe Ortalo wrote: teunis wrote: mutex locking time is... *heh* around 26000 microseconds... Longer than poll() Go figure. So much ? Well, it must be implemented via a system call then... Well, with threads managed by the kernel it is not so astonishing, but you can surely do much better if you only want to lock in-memory data structures... Which library do you use for threads/mutexes, linuxthread ? POSIX ? linuxthreads - ie threading that comes with glibc-2.1 Oh. by the way, while I'm thinking, how did you do your benchmark ? An empty lock/unlock I guess ? Not by two threads on a uniprocessor I hope (this environment implies a scheduling so... here is your implicit system call) gettimeofday(). Yeah, I know, there's better ways. If anyone can tell me - please! I'm guessing at this at every step. All I know now is with -all- the I/O handling removed from the movie handler except for movie decoding the thing finally plays fluidly on my computer. Most of the time. I think my code's pretty poor actually for movie playing but I don't know how to do it better. Now on the flip side, it'd be very handy to have a libGGIthreads library or something to give one a threaded interface to -all- of GGI. Hmmm. With additional delays, I don't know if it would be worth the work (especially as everyone would try to use for hype and then go back complaining about the performance)... Nevertheless, your application is very interesting with respect to this issue of real-graphic-world MT programming ! Thanks :) [code at http://www.geocities.com/winterlion... its the 'ggiplay' proggy :] It plays linux quicktimes. And mp3's *giggle*. And mpeg-2 multimedia though the renderer's broken. Gonna write my own soon. G'day, eh? :) - Teunis
