Hey guys,
First off, it is a little while since i posted here, but that is due to the fact, that I am studying computer science now..
Which lead me into the idea, that we need a "performance/algorithm" guide, at least something to point to. When searching for the word "algorithm" the scheduler algorithms is the really once to come up .. and performance is rather the same..
So i could write a lot of standard algorithms, but that would be kind of boring (if I’m the only one) so if people think it would be a great thing to have, i could dedicate some time for it... (I’m not sure about the structure, but what about Disk performance, and alike, such "guide/tips" could be merged into an article.)
KMT DK
idea: performance guide
Moderators: JAAman, klange, Octocontrabass, sortie, kmcguire, chase, thepowersgang, Owen, Combuster, AJ, 01000101, carbonBased, Candy, pcmattman
idea: performance guide
well, what to say, to much to do in too little space.
when it goes up hill, increase work, when it goes straight, test yourself but when going down, slow down.
when it goes up hill, increase work, when it goes straight, test yourself but when going down, slow down.
Re: idea: performance guide
What constitutes a "good" algorithm is very much domain-dependent. You can optimize for latency, for memory footprint, throughput...
Generally speaking, and as far as I can speak "for everybody", the idea of this site is to not provide building blocks for copy & paste programming. You need to understand what you are doing in order to get anywhere. Providing copy & paste frameworks just means people get stuck in even more screwed-up situations (instead of failing early, e.g. in setting up a cross-compiler).
If somone cannot come up with good algorithms himself, cannot even be bothered to check readily available online resources, and needs a "library" of ready-made algorithms to get it done --- then OSDev isn't a good hobby for that person.
Generally speaking, and as far as I can speak "for everybody", the idea of this site is to not provide building blocks for copy & paste programming. You need to understand what you are doing in order to get anywhere. Providing copy & paste frameworks just means people get stuck in even more screwed-up situations (instead of failing early, e.g. in setting up a cross-compiler).
If somone cannot come up with good algorithms himself, cannot even be bothered to check readily available online resources, and needs a "library" of ready-made algorithms to get it done --- then OSDev isn't a good hobby for that person.
Every good solution is obvious once you've found it.
Re: idea: performance guide
kmtdk wrote:So i could write a lot of standard algorithms, ...
IMO the important part of OS development is to design clean and elagent relationships between kernel entities. The implementation details that uses those algorithms is relatively minor, and most algorithms are very well searchable & documented on wikipedia and google.
-
FallenAvatar
- Member
- Posts: 283
- Joined: Mon Jan 03, 2011 6:58 pm
Re: idea: performance guide
I think an article could be added about performance. Not exactly how to write "high-performing" code because as Solar said, it is all very domain dependent.
But a quick article that is for when someone has a kernel up and running, and have hit performance issues. Just a quick list of places you should make sure are performing well are:
- Task Switches
- kmalloc/malloc
- etc.
Just some places people can look at their own code, and learn how to improve it because they can actually see a possible fix/increase in performance.
Other generic things could be added I'm sure, but I can't think of any right now.
- Monk
But a quick article that is for when someone has a kernel up and running, and have hit performance issues. Just a quick list of places you should make sure are performing well are:
- Task Switches
- kmalloc/malloc
- etc.
Just some places people can look at their own code, and learn how to improve it because they can actually see a possible fix/increase in performance.
Other generic things could be added I'm sure, but I can't think of any right now.
- Monk