Optimizing Rockbox Sources

[ant]

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.

[bk]

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.

[saratoga]

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.  

[Bagder]

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! ;-)

[Sentertainment]

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.

[JdGordon]

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

[Sentertainment]

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

[JdGordon]

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)

[bluebrother]

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

[Sentertainment]

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

[Llorean]

Why do you want to allocate for "the system" dynamically. What buffers that the system currently use, do you feel could be larger?

[Sentertainment]

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.

[safetydan]

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.

[sloth]

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.