T-DOSE (II)
Excuse me for the brevity of the previous post, it was done on my mobile phone (per experiment), and thus I was limited in the amount of characters I could post.
I just returned from Eindhoven (which, by the way, is the most ugly city in the Netherlands), and all in all I had a fun day. I went to see two talks: one on KDE 4 programming by Adriaan de Groot. I met him six years ago, when I was part of the Dutch translation team and we celebrated five years of KDE. He announced technologies, that for us as Haiku lovers, weren’t all that new. For example: finally KDE introduced Thread Weaver, an API that provides a job-based interface to perform tasks in threads. Of course, since X is always limited to the single-thread event model, this still makes the GUI run in a single thread. He also introduced an API to play sound files with three lines of code. We already have that one! Seriously though, it was nice to see some of the cool things such as Sonnet, an integrated spell checker that is applied to almost all text input, and Solid, an abstraction for hardware. Whilst this is extremely useful for KDE, since it runs on many platforms, the cleanliness of the API (on first sight) might provide some interesting ideas for Haiku as well.
The second talk I could enjoy was one by Joern Engel, on efficient data structures. While I’m not a very technical person, I did enjoy his talk. He outlined different ways to store data, in linear lists, in hashes and in B-trees, and explains their efficiency based on speed. His idea is the following: since RAM essentially is a high-latency, high-speed data storage medium - with current hardware advancements, hard disks have the same speed - and the L1-cache has become the low-latency memory, we need to work as efficiently as possible when creating data structures. By predicting what the CPU will prefetch into the L1-cache, we can pick data structures that fit best what we do with our data. He calculated what operations were most efficient on B-trees, on hashes and on linearly stored data. Conclusion: certain types of B-trees have the most advantage, and sometimes a hash can be very efficient, depending on the context, but “if you want to use hashes, use B-trees instead”.
Afterwards we had the ‘social event’, we went out for diner. I’d like to thank the organisation for their generosity: for the speakers, the diner was on them. During the diner I had the time to talk to some interesting people about Open Source (yes, we had the MIT versus GPL debate - luckily I’m good at debating), about the difference between Dutch and Flemish, and so on. I also got to lobby people to come to my speech tomorrow.
Anyway, I’m going to work on the speech now: due to the fact that the crowd is a lot more geek than I expected, I’m going to transform the speech into a more technical one. For tomorrow, keep your fingers crossed for a good turn-out!
nielx's blog
- RFC Coding Guidelines: Formatting Class Member Declarations
- Haiku Developer Tools Update (October 2023)
- HTTP Network Services Preview in R1 Beta 4
- Rust on Haiku: the Case of the Disappearing Deceased Threads
- The State of Rust on Haiku - July 2018
- Haiku has No Future
- Alpha 1: A Week Later
- A Jocund Eulogy
- Git for Haiku (#1)
- Haiku Alpha 1 Status Update (#2)