Ingo Weinhold escreveu:
Then recently Ingo found and tracked down a bug where our semaphore code was not really working as expected and ended up doing what seems to be a complete rewrite of our locking primitives. Well, giving credit where credit is due, this was probably, at least on my configuration, the single change in Haiku with the most impact since we actually managed to run Tracker on it. Not only Haiku feels a lot faster now (compiling it inside itself seems to be at least one order of magnitude faster) as the last bug I was still getting (a random mimeset failure while building) is now gone. I managed, again, to build Haiku (up to a point, see below) inside itself!Really? 8-OThanks for the praise, but I'm utterly surprised, that my changes would have any such impact. The semaphore bug should only have been triggered in very rare circumstances -- which is probably why it hadn't been discovered before (I only saw it when reading the code). Regarding the restructuring of the locking primitives, that shouldn't have any noticible performance impact yet. Well, our snooze() performs better now. :-P And since a few hours also blocking reads from pipes.
Maybe it has, for some reason, a bigger impact in a my configuration (which is now a Intel Core 2 Extreme with 4 cores at 3.83 GHz and 12 Mb of L2 cache)? The difference *IS* impressive. Before these changes compiling under Haiku was similar to compiling under ZETA (to be fair, it was faster under Haiku but not, say, 2 times faster) and now it is similar to compiling under Linux (although, as expected, Linux is still faster). In any case, you did manage to fix the random mimeset error I usually got (General OS Error) and that is good enough for me. :)
Anyway, take a look at bug #2142 as this is where it is stopping now (I compiled Haiku 4 times in a row just to be sure and it stopped at the same point all the time).
[...]2 - I started to get some new KDLs in the block cache after Ingo's changes. It seems to be easy to reproduce when trying to start firefox after compiling Haiku inside itself. I will also create a bug about this.I wouldn't rule out that my changes are to blame, but there's already #2059, which predates them. Incidently I've just ran into the same bug and am trying to analyze it ATM. I haven't come very far yet, though. I've only understood that the block cache's pending_notification list has somehow become corrupt (the notification's next link has an invalid value which causes the crash when removing it from the list).
I got another one in net timer. Check bug #2143. I am pretty sure this is related to your recent changes as, if I am not mistaken, you did change how timers work.
-Bruno
