Rockbox Technical Forums
Rockbox General => Rockbox General Discussion => Topic started by: Sentertainment on December 30, 2006, 11:13:59 PM
-
Ok, I'm new tto the rockbox community....so I do have alot of questions and such and I've been having trouble with one mod in particular (I do understand why, I just wish I could explain plain and simple I actually know a thing or two and I am here to help)
Anyways, I wasn't sure where to put this and I just don't feel a topic like this is fit as a patch.
So...to get started, I just began examining the source and such and am finding a few things I feel could be improved. (while they aren't huge things, seeing these functions called 100xxx times, it can add up)
Well, I've started at the menu code as I want to improve some GUI functionality (and speed) of Rockbox.
First I came across a menu limit and am curious as to why this is so.
Second I came across a few things that can be possibly "improved" in menu management.
*keep in mind I have little free time and this is after looking at the code for about 10min
Well, I saw the code for freeing a menu and I feel the whole structure can be improved using dynamic arrays.
This would minimize this:
static int menu_find_free(void)
{
int i;
/* Tries to find an unused slot to put the new menu */
for ( i=0; i if ( !inuse[i] ) {
inuse[i] = true;
break;
}
}
if ( i == MAX_MENUS ) {
DEBUGF("Out of menus!\n");
return -1;
}
return(i);
}into nothing...
There are some minor drawbacks to the management ideas I have, but I feel doing things more dynamically in memory would help optimize structure alot. (also open more hopes for memory leaks, but if you know what you're doing...not problems there)
Also, doing things dynamically would automatically decrease memory usage in most cases.
It's been about 6months or more since I last used C++...but I will brush up and try to make some new code patches myself.
I'm just listing out things I see to get my ideas and seriousness started.
-
There is no dynamic allocation of memory in the core in Rockbox.
-
There is no dynamic allocation of memory in the core in Rockbox.
So...isn't that what my goal is to do? :P
Not everything would benefit like I said, but alot of reiterating statements (such as that 'if' shown above) could be wiped out or even optimized more.
Anyways, are you telling me the arm processors and memory management wont support this? I honestly don't see how it wont, if it doesn't support it I would say it would be at the compiler's fault (I could be wrong). Maybe I'm confused or I'm just not getting the idea...I don't know, lol
-
You said your goal was to do things more dynamically by using dynamic memory allocation. You didn't make mention of adding it, so I wasn't sure you realized that it didn't exist within Rockbox.
It has often been stated that it is not wanted within the core of Rockbox. Come into the IRC channel and ask about it, if you would like to try to argue the case before the main developers (assuming you can catch them online).
-
You said your goal was to do things more dynamically by using dynamic memory allocation. You didn't make mention of adding it, so I wasn't sure you realized that it didn't exist within Rockbox.
It has often been stated that it is not wanted within the core of Rockbox. Come into the IRC channel and ask about it, if you would like to try to argue the case before the main developers (assuming you can catch them online).
Yeah, sorry if I seem a bit scattered as I had a long day at work...I was talking about adding that (more-or-less modifying it in)
Thanks for the heads up, it's starting to get me wondering so I'll probably give that a shot. KNow what time (say in GMT to avoid confusion, lol) would be best to get on IRC to catch a dev or two?
-
The problem with dynamic memory allocation is you need a pool of unused memory to allocate from.
This conflicts with the desire to have as big an audio buffer as possible so the disk spins up as little as possible.
The prevailing view is the memory pool would be near enough the same size as everything statically allocated and so the simplest method won.
-
http://rasher.dk/rockbox/ircstats/all.php
Look at the most active nicks list, and pick a time when most of those are likely to be online. Pay careful attention to amiconn, because he's likely to be one of the strong arguers on this point. :)
-
The problem with dynamic memory allocation is you need a pool of unused memory to allocate from.
This conflicts with the desire to have as big an audio buffer as possible so the disk spins up as little as possible.
The prevailing view is the memory pool would be near enough the same size as everything statically allocated and so the simplest method won.
OK, does make sense....
After knowing that, it is probably the most simple by far. Is this also the way the default software (on the iPod) works? I know it's optimized for the iPod, but even so the menus are significantly faster, not to mention much more graphical and animated.
Also, I think I may look into the operation of the audio buffer...I'm sure there have got to be more ways to optimized this or even an alternate way of allocating memory so some can be dynamic and some static.
-
The advantage the iPod menus have is that they're actually *less* dynamic than Rockbox's. Because the background is set, and there's only the builtin font, less work needs to be done with line scrolling and other things. There are probably a whole range of tricks that could be done if Rockbox only had a built in font, and no backdrops.
I'm not saying this is definitely the reason, but it's a start. Another thing is CPU usage. Go into the debug menu and boost the CPU without music playing, then scroll through the menus (preferably without a backdrop image) and depending on your player (I don't know how noticeable it is on 5G) you can see some speed difference in the menu from with the core unboosted. One of the problems is that we draw slowly, another is that we could use a much better wheel driver.
-
All understood...but then I have another question for that... :P
Couldn't you reserve a small amount of memory for certain things to be cached?
I haven't gotten far enough to look at the usage of fonts or anything even bear that (i don't even know the font structure, lol)
But you COULD easily render parts of images and cache it for later usage.
Anyways, give me some time to talk to the devs and look at the code more and then I'll be in a better position to discuss optimizations...like I've been hinting at, last night was my first compile and today is my first time actually reading the code. (I've only had rockbox running on my iPod for 72hrs or so)
-
I have been trying to get dynamic memory allocatio into the core for some time, but its not going to happen in the forseeable future (like Llorean said, amiconn is a very vocal opponent to this and Im not really in a position to argue with him.)
The basic points against it are:
- needs a pool to be allocated from (so reducing the available audio buffer). some targets have less than 8mb RAM so we have to be very carefull with what uses it.
- adds code complexity (having to worry about checking the memory actually was alocated)
- waste of time because anything that can be done dynamically can be don statically (although with possibly more RAM usage then needed)
- would mean certain features might not be able to be used on the low mem targets becase there is no RAM for the malloc pool.
As for your other ideas, we look forward to patches.
The best place to actually talk with devs is on IRC or the dev mailing list, and patches go on flyspray.
-
I recently talked to a guy working on embedded systems, and he told me dynamic memory allocation is not allowed within that stuff in their company because of security reasons. With dynamic allocation you can always run out of memory and how do you want to catch or display that? Only when using static allocation you can make sure what amount of memory is needed and that this memory is sufficient in all cases. That discussion was regarding the automotive sector, so it's pretty much more critical than in some dap. But I too agree that dynamic memory isn't a good thing on small embedded devices -- it gets really hard to control.
The speed issue is much because of the fact Rockbox currently uses only one CPU on ipods and hasn't optimized. On my h120 it works like a charm and there's nothing sluggish in the menus or while scrolling at all.
Btw, Rockbox is written in C, not C++. While they have some similarities there are also quite a lot of differences someone should be aware of ... especially the view on how things should work.
-
And for that reason I agree that rockbox shouldnt have dynamic memory as the defacto memory allocatio scheme in the core. BUT I think it should be used for stuff like the buffers for the wps images, and other "fluff" stuff which dont really affect usablility but they are nice to have (e,.g multiple fonts. If people want more than 1 why should everyone lose audio buffer for that?)
Las note on this tho. rockbox does has a minimal dynamic memory allocation system which can be allocated from BEFORE the audio is initialsed which is probably the compromise, (its only downside is buffers egt allocated in entirety at boot and cannot be deallocated)
-
I have an idea how to implement dynamic memory allocation. It would eliminate at least the issue with the memory pool, so every target would protfit of more avilable ram and in the end longer playtime.
Divide the ram in blocks of say 100kB. Each block can eather be used for dynamic memory allocation or for audio buffering. If you use a simple wps you need less memory for the wps, so more memory is avilable for the audio buffer. The memory is always fully used.
If the user starts a plugin that needs memory, the memory manager grabs a block from the audio buffer that was already played and makes it avilable for the plugin. If playback is still in the first block of the audio buffer the last block of the audio buffer is sacrificed.
-
I think the audio buffer is used as a ring buffer, so the start, end and size are all needed at init.
-
I think the audio buffer is used as a ring buffer, so the start, end and size are all needed at init.
I can't see the problem. Each block has a pointer to the next and the last block and the end is connected to the beginning so it is still a ring.
-
I have an idea how to implement dynamic memory allocation. It would eliminate at least the issue with the memory pool, so every target would protfit of more avilable ram and in the end longer playtime.
Divide the ram in blocks of say 100kB.
So you inevitably would waste a significant portion of 100kb most of the time (partially used block). On some targets with very little RAM (I think ifp only has 1MB total) that's not acceptable.
Decreasing block size would increase your pointer stack overhead, also wasting memory.
Being used to PCs at first I was a little annoyed that malloc is not available in Rockbox. Over time though I began to appreciate the wisdom of this approach. Debugging on embedded targets is difficult enough without having to deal with dynamic allocation issues.
-
I have an idea how to implement dynamic memory allocation. It would eliminate at least the issue with the memory pool, so every target would protfit of more avilable ram and in the end longer playtime.
Divide the ram in blocks of say 100kB.
So you inevitably would waste a significant portion of 100kb most of the time (partially used block). On some targets with very little RAM (I think ifp only has 1MB total) that's not acceptable.
Decreasing block size would increase your pointer stack overhead, also wasting memory.
#define the block size so that it can be adjusted depending on the total memory available.
-
No matter how you plan or think this should be done. feel free to write a detailed proposal and I'm quite sure we will shoot it down.
We have this "we need malloc"-argument repeatedly over an over again until the newcomers realize and understand our viewpoint and our reasoning and then we end up again where we started: without malloc or other dynamic memory usage...
Welcome to the world of grumpy old hackers! ;-)
-
I have an idea how to implement dynamic memory allocation. It would eliminate at least the issue with the memory pool, so every target would protfit of more avilable ram and in the end longer playtime.
Divide the ram in blocks of say 100kB. Each block can eather be used for dynamic memory allocation or for audio buffering. If you use a simple wps you need less memory for the wps, so more memory is avilable for the audio buffer. The memory is always fully used.
If the user starts a plugin that needs memory, the memory manager grabs a block from the audio buffer that was already played and makes it avilable for the plugin. If playback is still in the first block of the audio buffer the last block of the audio buffer is sacrificed.
ya, that would be compiler level....would be inefficient to do that in the level we code in.
(as many others have been saying also)
Anyways, since this topic picked up so fast, I thought I would put in my 2 cents (I was going to wait until I finished planning/figuring me idea)....well....
Here goes, let's say we reserve the memory for the audio buffer right on the spot, it's pretty much static. I haven't looked how the buffer is structured, but if we set limits for everything accordingly...the two shouldn't interfere.
I am aware this adds complexity, but if done properly, the optimization gained would be well worth the effort.
*As for badger's proposal, I do appreciate the way you said that...
I feel I can understand both standpoints...But I am sure some dynamic allocation can be used if programmed properly. In this case, it's obvious I will need to examine the structure of the audio buffer and then I can actually be at a standing point where I could truly say whether it's worth it.
-
The way the RAM works is that on init, the parts that need an unknown amount of ram (dircache, tagcache if loading into ram, some other stuff) all get initialised before audio_init(). once that call has been made it is impossible to call buffer_alloc anymore because the rest of the ram is used for the audio buffer.
For things that use heaps of ram but arnt accessed often (like the playlist viewer) can always steal the plugin buffer (512kb on targets with more than 9mb ram iirc) which is usually plenty. Of course, this means that this feature cannot be used while a plugin is running (we have TSR plugins (they are exited, but still running in the background))
-
The way the RAM works is that on init, the parts that need an unknown amount of ram (dircache, tagcache if loading into ram, some other stuff) all get initialised before audio_init(). once that call has been made it is impossible to call buffer_alloc anymore because the rest of the ram is used for the audio buffer.
For things that use heaps of ram but arnt accessed often (like the playlist viewer) can always steal the plugin buffer (512kb on targets with more than 9mb ram iirc) which is usually plenty. Of course, this means that this feature cannot be used while a plugin is running (we have TSR plugins (they are exited, but still running in the background))
ok, so here's one way of thinking of this...reserve the ram as dynamic (best way I can think of to explain). Just because it's dynamic can't mean it can't have reserved memory or a cap on it.
Basically, it would be stored the same as if it were static, but used dynamically to optimize code.
Are you starting to get the idea? (yeah...it's hard for me to explain)
Edit:
for example, Rockbox uses static arrays...they (in basic) have a reserved amount of memory.
But what if we switched it to dynamic and caculated the "cap" as if it were going to be static...in other words, there would be a limit and reserved amount of memory.
This may be possible, which would allow the audio buffer to be accounted for.
(you know, pointers are XX bytes, etc...calculate the max memory that could be used when it has reached the max in array)
and wow, I must say...this topic was meant to be for a broad range of optimizations and we seem to be fixed on this idea of whether or not dynamic memory could be used....
-
I dont think I follow. You want to allocate X bytes for the audio buffer and use the rest for the various other buffers?
I dont see how this is any more efficient than allocating at compile time X bytes for static buffers (99% of the everything else), Y bytes for the more dynamic stuff at init and the rest for the audio buffer.
Using a straight block of RAM for the audio buffer is for sure faster than using a linked list like was suggested (although, I have thought about something like this in the past). And using the current method means the only parts that need to check the memory allocation are the 1% of things that grab it on init (and so shhuold be able to assume they will get the ram)
-
and wow, I must say...this topic was meant to be for a broad range of optimizations and we seem to be fixed on this idea of whether or not dynamic memory could be used....
That's simple ... you started with that "we need malloc" thing. Rockbox doesn't have malloc and it is not wanted. As Bagder said, this gets proposed again and again and doesn't change anything.
Btw, I don't think it's a good idea to know Rockbox for a couple of days and start speaking of "optimizations". Rockbox is a firmware, which makes it quite different from a usual PC program. This also means some decisions are different, and if you work a while with it you'll recognize that the way it has been decided is the only useful way for a project like Rockbox. The Rockbox hackers are really good, and unless the low level issues are resolved "optimizing" the higher level stuff doesn't make too much sense IMO.
Me likes being a grumpy old man :)
-
ok, like I said...I see where all of you guys are coming from, but that doesn't mean things can be done differently to optimize at a high level.
It's similar to the concept of recursion, etc...just because it may not seem like a dramatic change doesn't mean it wont be in the end.
Here's my proposal after what I've read and seen...
Calculate a max amount of memory to reserve for the system and then statically reserve the audio buffer...then, you can pool from the leftovers (the memory calculated for the system) dynamically.
And...at my standpoint, I am going to aim for this until either I come across a coding block and get stuck or someone finally convinces me it just can't be done.
I know I may seem like a stubborn fool, but I'm still not convinced it can't be done or that it can't be used to optimize the system.
Either way, I would rather like to stop arguing over whether it should be done or not...if you have a reason for why it shouldn't be done and nobody else has mentioned it, go ahead....but I feel alot of what is being said is redundant and until new information is brought to mind...I don't think any side will change their mind(s).
*and that;s the truth, probably the first thing we can all agree on, lol ;)
-
Why do you want to allocate for "the system" dynamically. What buffers that the system currently use, do you feel could be larger?
-
Why do you want to allocate for "the system" dynamically. What buffers that the system currently use, do you feel could be larger?
I don't want to do that to make it larger, no current need for that (at the moment).
Reason being is the code can be restructured in such a way that loops wouldn't be needed for commands such as menu_find_free() wouldn't require loops...and possibly not even be needed at all if done correctly.
The reason I brought this whole idea of dynamic allocation up is because it would allow for greater optimization of certain functions.
(dynamic allocation could allow for array keys to be removed fast and eifficiently, or even relocated to an alternate array to identify them as being inactive rather than using 'for' loops to scan through the arrays like that)
Maybe now that I've (hopefully) explained it better, either you can come up with a better comeback or agree with me....either way, as long as I get some feedback I'll be happy. :P
-
To me it seems like you're looking at optimising the wrong areas. The menu code snippet you've posted is unlikely to be the bottle neck for any performance issues you've seen. Bigger issues (particularly for iPods) are just the time it takes to redraw the screen (or was last I heard).
You keep saying that you want to "optimise" Rockbox, but haven't actually pointed to any areas that are actually measured to be slow. Maybe start by profiling things to find bottlenecks rather than guessing and proposing massive changes to memory handling to fix a problem that may not even be a problem. Heck, I think Rockbox already has a profiling system, though I'm not sure what state it's in. Start there.
-
Reason being is the code can be restructured in such a way that loops wouldn't be needed for commands such as menu_find_free() wouldn't require loops...and possibly not even be needed at all if done correctly.
Not really. There would be a loop, or equivalent, it would just be hidden away inside of malloc.
I can agree with both sides of the malloc issue, but on the whole I think the RB devs have it right and doing things as statically as possible is a very good thing, especially as parts of the system are quasi realtime.
And the argument that it makes and already difficult debugging task that much easier make a lot of sense.