6.20.2011

Offline repost #8: insight and responsiveness

Somehow, KDE seems more responsive than GNOME/Gtk. Simply FASTER. The fastest desktop I experienced in the past where Openbox and other ultra-minimal ones. But KDE really puts a crown on it with it's full desktop functionalities. I should've listened to my fellow students in the past. I haven't yet encountered someone using Linux and GNOME (except me, but that's over now!). Anyway, another thing came to my mind today while installing on the laptop and coding on the desktop: my paranoid inline use in C/C++. This didn't come on it's own, I was thinking about how to design the bytecode for my programming language. A little brainstorming session resulted in a deeper understanding of stack use in C and assembler. I won't cover this in total, but it's incredible that every local variable lies by default on the stack if it doesn't go into a register. Since my language doesn't feature any registers under the hood, I will need to heavily use the stack for anything internal - even global variables. The point is that there is theoretically no global memory in my language. Everything is local and variables in the upmost layer and visible to everyone. Easy! Plus that they can also stay in the stack. However, I realized that my excessize use of inlining if rather... not necessary. Think about it: parameters get pushed onto the stack, GCC is able to create specialized function instantiations for certain static parameter values. Of course does this not apply to already compiled files, but seriously - does it really improve performance soooo much that it's more worth than having a know, constant call time? Of couse can GCC prevent inlining in case of too big code results and analysing statistically, to squeeze out a bit more performance. But that doesn't change the fact performance will possibly bump back and forth when doing so. I had a lengthy discussion with myself about why I want to force everything inlined, making it even more uncomftable to manage and compile projects. And I came to the solution that it's better to not rely on inlining in this case. What will happen if decided to use it on the NXT? Will it blow up the file size and slow down cause I didn't use it wisely? Well, using functions reduces this to a minimum. A bit less performance, yes, but the problems always lie in alghorithmic and case-specific moments. Certain things take my time. This is one of them. And in the end I don't need to worry about anything and let the optimizer do his work. I'm getting into situations where it's hard to reduce code size in certain functions. Good that I sorted that out.

So that's it, here we go! New workspace, new philosophy and no sweets in sight. Where is this paradise anyway...

Oh, and you should really check out Kate as your new, favorite editor! It's a huge improvement over gedit or other silly gtk editors. May be a bit weird the first time using it as a previous GNOME user, but I can't help loving it's features so far.

No comments: