On Wed, 7 Sep 2016 08:13:54 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> said:
> > Assuming it's what we talked about on IRC, I'm happy with it. It's > > essentially an implementation what I wanted from the beginning (Eo being > > single threaded and if you want multi-thread, do something like > > socketpair()) with the added coolness of enforcing IDs are unique per > > thread. We'll probably need to change the error messages about ID not > > found to maybe check the other threads if the ID is valid there so we > > can say something like: "You tried accessing object X from thread Y, but > > it's actually an object of thread Z. DENIED! Read more about foobar().". > > > > My only concern, as always, is performance. I know you said locks are > > slower than TLS, but while we only needed to lock on write, now we use > > TLS on both read and write, so it is a concern. > > > > Hope it pans out well. I'm looking forward to seeing benchmarks (and of > > course, tests with threads and etc). :) > > well it's just as slow as the spinlocks... as long as i have the optional > locking support. literally the if (tdata->shared) or if (domain == shared) > then lock+unlock ... just that alone that if causes it to go from 2.5% to 5%. > without the if we are back to almost pre-locking speed (a bit worse. w vs 2.5% > ) plus all the goodies. > > so choices: > > 1. drop the idea of shared objects at all and you HAVE to send an obj > (socketpair like above plus fd passing where ownership transfers). > 2. find some way to optimize this... this is not easy. i've tried a few so > far. i'll try some more, but i suspect i'll hit a wall. > 3. give up and accept the fate of the lock! > > i dislike #3. #1 is the frontrunner BUT i won't go there until #2 is well > beaten into a pulp. i actually had an idea in bed that .... may help. i > noticed the asm output/dump matching the c code seems to have a LOT of the > actual if handling interspersed with the code and maybe just maybe all the > if's and their child code cause a l1 cache miss to l2 since the cachelines > are not packed with instructions we execute, so moving all the error handling > to one big error block at the end might be an idea... another idea i have as > to the cost of THESE if's it the speculative execution. the cpu might be > executing BOTH branches ready to throw away one of them ... but since one > branch is a spinlock this causes a huge cpu stall anyway as it snoops caches > with other cpu's etc. and so everything suppers as if we actually called the > lock anyway. if this is true... UGH. PAAAAIN. scratching head right now as to > a solution. well well well... my ideas of the l1 cacheline + instruction fetching were right! i'm down to 2.7% WITH optional spinlocks. how to fix this? move all slow-path error handling to a bunch of goto's at the end of the function (one label + return NULL per error type). with gotos this moved the error handling form continuous in memory to "at the end of the function in a block" and presto... speedup. well wel well. i'll be. i never considered this before. mental note. keep in mind the instruction cache + cahcelines. they say "don't use goto". begone ye pesky comp sci theorists... goto is AWESOME! seriously. this is a major thing. we have TONNNES of if's in our code. TONNES of them, often for handling odd cases that sometimes happen. if the handling is really anything more than "return" or "break" or "continue" or a simple op (i++, i=10, i--, etc.) AND its not a common path (EINA_UNLIKELY) it is TOTALLy worth putting the case handling code in a separate code block. there is a real measurable speedup. in real life. no callgrind or virtual cpu stuff.. with real memory and real caches and so on. well well well. i hereby BLESS the goto and encourage its use for any "rare case handling" as above. (actually the code is more readable too!) :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
