sunaku / wmiirc

Ruby configuration for WMII window manager
ISC License
82 stars 26 forks source link

Cooperative Multithreading #20

Open nougad opened 13 years ago

nougad commented 13 years ago

I measured battery usage with and without X and found a big difference (6W vs 11W). Of course my wmii config causes only a small part but I mentioned many wakeups by it. So I try a short profiling and see many time are consumed for all the thread stuff (synchronize, pass, etc). I thought about Cooperative Multithreading and want to know what you think about.

I would try it with two threads: One Thread waits that an event occurs and sleeps meanwhile. The other handles the status bar updates. This scheduler used a queue for update events (e.g two buttons A updates every 2 and B every 5 secs): | A | A | B | A | -- first sleep 2 secs, execute update method for A, sleep another 2 secs, call A, sleep one sec, call B, sleep one sec, call A. Of course some corrections required because update needs some time too.

I don't know if this effects any performance improvements but I give it a try. What do you think?

sunaku commented 13 years ago

Good idea. We could try using Ruby 1.9 fibers with a global queue. Each fiber would yield to the next one by:

queue.enq current_fiber
next_fiber = queue.deq
next_fiber.resume

This is a simple cooperative round-robin schedule.

Another approach is to try using libev (via rev or eventmachine) to read wmii's /event stream. But I have no previous experience with these libraries.

sunaku commented 13 years ago

@nougad I just re-read this issue report and, at the end, it sounds like you already implemented this idea. Is that true?

nougad commented 13 years ago

Sorry, as I opened the issue I only searching for some Ideas. I looked a little bit at eventmachine and think this would be a good starting point but sadly it's still on my todo-list. Hopefully I get some time next month. I think this issue are not very complex but I haven't started jet.

sunaku commented 13 years ago

The main cause of power-inefficiencies in Ruby 1.9 was a timer-thread issue. It has since been fixed, so perhaps your battery lasts longer now?

nougad commented 12 years ago

No, I updated today to ruby 1.9.3p0 (2011-10-30 revision 33570) [i686-linux] but in my opinion it takes still to much battery. powertop reports up to 4.5W which is 1/4 of my complete usage. I played around with fibers over Christmas but don't have any working code till now.

Edit: Ok, I also updated to your latest config (hard work^^) and it seams way better. It has still some peaks but most of the time it looks perfect.

sunaku commented 12 years ago

Interesting, I will need to study my powertop output more closely. I was only looking at the number of wakeups because that was the initial problem ruby < 193 had.

Glad you could upgrade to the latest version. I have more (hopefully internal) refactoring that I'll do this weekend. After using DWM for a month, I learned many lessons about what is essential and what isn't with respect to WM configurations. Cheers.

sunaku commented 12 years ago

Hey @nougad, my powertop isn't reporting power usage estimates so I'll have to compile my own kernel or something. :(

nougad commented 12 years ago

I use powertop 1.98 beta which is much better than the stable release. I think the current code is hosted here: http://meego.gitorious.org/meego-developer-tools/powertop

sunaku commented 12 years ago

Alright, I'm running powertop 1.98 now and this is what I see while writing this reply:

Summary: 345.7 wakeups/second,  0.0 GPU ops/second and 0.0 VFS ops/sec

            Usage       Events/s    Category       Description
       456.3 µs/s       0.6        Process        ruby /home/sunny/.wmii/wmiirc

Where are you getting that wattage information (ruby consuming 4.5W) from?

nougad commented 12 years ago

Can't say why the first field is missing: