Optimizing Rockbox Sources

[Sentertainment]

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:

Code: [Select]

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.

[Llorean]

There is no dynamic allocation of memory in the core in Rockbox.

[Sentertainment]

There is no dynamic allocation of memory in the core in Rockbox.

So...isn't that what my goal is to do?
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

[Llorean]

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).

[Sentertainment]

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_winch]

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.

[Llorean]

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.

[Sentertainment]

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.

[Llorean]

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.

[Sentertainment]

All understood...but then I have another question for that...

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)

[JdGordon]

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.

[bluebrother]

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.

[JdGordon]

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)

[ant]

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.

[JdGordon]

I think the audio buffer is used as a ring buffer, so the start, end and size are all needed at init.