Rockbox General > Rockbox General Discussion
Optimizing Rockbox Sources
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:
--- Quote from: jdgordon on December 31, 2006, 09:44:41 PM ---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))
--- End quote ---
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:
--- Quote from: Sentertainment on December 31, 2006, 10:43:48 PM ---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....
--- End quote ---
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 ;)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version