- Debugger: Getting mixed signals
- 'Packaging Infrastructure' Contract Weekly Report #4
- Haiku monthly activity report - 06/2015
- 'Packaging Infrastructure' Contract Weekly Report #3
- 'Packaging Infrastructure' Contract Weekly Report #2
- GCI 2014 winners trip report (mentor side)
- TeX Live and LyX; Changes to the boot code
- 'Packaging Infrastructure' Contract Weekly Report #1
- Beginning of 'Packaging Infrastructure' Contract
- Haiku monthly activity report - 05/2015
Axel does not have a secret patch
Whenever I was with Axel and saw Haiku running on his IBM ThinkPad T40p, I was almost convinced, that he must have forgotten to commit a rather effective patch, though he swore that that was not the case. I have never seen the app_server perform so well on any other machine. When I saw this first, at the time I was working on a bigger patch to the app_server, but it was already taking me some time, and I was quite afraid that I had messed it up and must have made app_server much slower. But then I commited that work regardless and Axel installed it on his machine and it was just as fast. Before my patch to the BRegion implementation, which came some time later, Axel could degrade the performance by opening a couple more windows, but with the new BRegion code from XOrg, the app_server scales much better.
And now I have such a machine myself. My employer lend me his unneeded T40p and I swapped the harddrive with my installation. I'm sure that I run Haiku without Axel's secret patch and the performance is just as convincing as on his machine. So I must admit that Axel didn't, after all, forget to commit something.
Usually when I run Haiku, I think that we have got one long road ahead with our app_server. But running Haiku on this machine, which has much weaker specs by the way than my other computer, I'm tempted to think there is nothing left to do but fix bugs. The difference is like night and day! Not only is the window redraw absolutely instant without any lag, it is not even using a lot of CPU either. What is the secret of this little machine? Is Haiku bombarded with unkown interrupts, possibly power management related, on newer hardware? Is the IBM using shared memory for the frame buffer (I would think not)? Is our scheduler in love with the first generation Pentium-M and it's chipset? I have no idea, but I'm very curious to find out what it is, because if my other computers are not an exception, it could be very useful information with regards to "unlocking" Haiku on newer and much more powerful machines. I'm interested to know how Haiku performs on other peoples real hardware. Is there a strongly noticable lag when redrawing windows that are exposed by moving other windows, like I see with all my other computers?
- stippi's blog
- Login or register to post comments
Comments
Re: Axel does not have a secret patch
What about resizing columns in Tracker listviews? Is that working better on the T40p as well?
Couldn't the user experience benefit from a little cheating, by throwing away messages that were generated between the app_server began and finished acting on a specific event? Maybe I don't have the right understanding of what happens.
Would it be useful to watch (and try to analyze) the app_server and kits on an unprioritized fifo scheduler?
Re: Axel does not have a secret patch
I have had a look at our TruncateString() implementation, which seems to use most of the CPU when resizing tracker attribute columns, but it seems fine, except for one little inefficiency when it asks for the width of the "..." glyph. It could prepend that glyph to the first call to GetEscapements() and avoid one trip to the server, but I doubt this would result in great speed up. When I investigated some other issue, I found out that we have many more mouse moved messages in our client side queue (~50) compared to R5 (~2), and this is likely the real reason why resizing tracker columns is that slow. And yes, it slow on the T40p as well... :-) Tweaking the amount of mouse moved messages in the client queue will have to happen in the event dispatcher in the app_server. I'm hoping that Axel will do that one day, since he has originally written it.
Re: Axel does not have a secret patch
I have a ThinkPad Z60m, which more or less appears to be a newer version of the T40p. I've been wanting to try Haiku on it, and now I really want to.
I think it would be generally useful to write several performance benchmarking tools that stress various parts of the app_server in as specific a way as possible. Sort of like that little app Axel wrote to test the find_thread(NULL) call and see if using the stack pointer made it faster, but of course making calls to the app_server.
Tools like those might allow you to figure out why the app_server is so much faster on the T40p and then try to get similar performance on other machines.
Examples of benchmarks might be font rendering, drawing rects, drawing bitmaps, and calculating clipping regions (you probably already have this one.) If there are already tools like this it might be good to make a consistent framework for all of them and be sure you use accurate measurement techniques like Axel did in his code.
I'm sure we have plenty of other benchmarking tools from other platforms to get ideas from too.
Re: Axel does not have a secret patch
An alpha CD image should be released, to help people test Haiku on real hardware more easily.
Re: Axel does not have a secret patch
That's really interesting. Since this post is related to Thinkpads, I'll just say that every few weeks I build the Haiku tree on my Pentium 2 350MHz 600e (yes, it takes a looong time) and the app server performance hasn't stuck me as being particularly bad. Sure it's slower than R5, particularly in redrawing the background when dragging windows, but not terrible and way, way better than VMware on my P4 1.6GHz T30.
I'm looking forward to getting Linux cross-compiling working on the T30 and trying it natively on that machine.
Re: Axel does not have a secret patch
Now, don't forget to update the Haiku section of the BeOS Laptop Page and Haikuware, folks ! :)
Re: Axel does not have a secret patch
Let me show you how it is on my box:
http://www.simon-t.me.uk/trackerdrawing.avi (xvid with mp3 audio, under 4MB)
(to people who aren't stippi - download it if you want but it's not that interesting! I'm trying to lessen he load on the host (which is a university society that provide hosting for free))
In short - redrawing is actually pretty good, no noticeable lag on normal windows. Some lag redrawing a tracker window from the non-root volume - I wonder if that may provide a clue to a bug somewhere else. The video also shows some overall window resizing issues and the column resizing issue, just to be sure these are already known about (and are the same on my hardware).
What I forgot to say on the commentary is that I've also got an nvidia graphics card, which seems to be running accelerated. Apologies for the abrupt end, I waffled on a bit and ran Chart too, but it didn't add much of interest.
Simon
Re: Axel does not have a secret patch
Have you tried running a profiler(gprof) on both machines? You can activate profiling only when the mouse button is pressed to get more meaningful results. And you might profile not just the app server, but the kernel as well (is profiling possible for the haiku kernel?)
Re: Axel does not have a secret patch
That was an excellent idea making a video. You could possibly do the same test on R5 and make a video of it, could be interesting as well.
How did you record it? Stand video camera + LCD screen?
I don't have a stand for the vid cam but I could record Haiku as well and a P3 800Mhz and Ati Radeon 7500 so much older stuff.
I'd like to see more people doing this, it could test video and audio drivers as well this way.