| 01:00 |
| 01:03:54 | *** | Saving seen data "./dancer.seen" |
| 01:43:35 | | Quit Piece_Maker (Read error: Connection reset by peer) |
| 01:44:57 | | Join Piece_Maker [0] (~Piece_Mak@cpc95746-bolt17-2-0-cust360.10-3.cable.virginm.net) |
| 01:57:08 | | Nick JanC_ is now known as JanC (~janc@user/janc) |
| 03:00 |
| 03:03:56 | *** | Saving seen data "./dancer.seen" |
| 03:29:38 | | Quit akaWolf (Ping timeout: 252 seconds) |
| 04:00 |
| 04:18:25 | | Join akaWolf [0] (~akaWolf@akawolf.org) |
| 05:00 |
| 05:03:58 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:04:00 | *** | No seen item changed, no save performed. |
| 08:00 |
| 08:23:48 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 09:00 |
| 09:04:04 | *** | No seen item changed, no save performed. |
| 09:27:49 | braewoods | speachy, _bilgus: i'm considering how i should size my read buffer. i've usually done powers of 2 to date, but does that matter for rockbox? is there any benefit to it being a power of 2 at the higher level API? if rockbox is doing its own buffering it may not matter all that much... |
| 09:31:39 | braewoods | i'm basically trying to write my own mini-allocation code for ZIP support to reduce waste of the provided "scratch paper" |
| 09:31:52 | braewoods | basically managing my own stack from what would otherwise be a heap allocation |
| 10:00 |
| 10:12:49 | | Quit massiveH (Quit: Leaving) |
| 10:13:18 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 10:14:46 | | Quit massiveH (Client Quit) |
| 10:15:05 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 10:15:38 | | Quit massiveH (Client Quit) |
| 10:15:57 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 10:16:07 | | Quit massiveH (Client Quit) |
| 10:17:26 | speachy | braewoods: size/resource use is more important than performance. and rockbox already has its own read buffering going on, so I'd not htink there's much advantage to anythin gover 512 bytes. |
| 11:00 |
| 11:04:08 | *** | Saving seen data "./dancer.seen" |
| 11:27:13 | braewoods | speachy: ok. thanks. |
| 11:29:01 | f1refly | braewoods: the size of allocated buffers should not make any difference on regular hardware. it's nice to go with familiar numbers tho as it helps to think about the problem imo |
| 11:29:08 | f1refly | so i get where you're coming from |
| 11:29:36 | braewoods | usually it's more about how much i have to keep in memory at once. |
| 11:29:59 | braewoods | i've been using larger reads just to avoid having to write more complex parsing code |
| 11:30:07 | braewoods | think like 64k or so at a time. |
| 11:30:40 | braewoods | otherwise i need something more advanced to refill my ram buffer or so and that's kinda involved when the whole data chunk is small enough to fit in RAM. |
| 11:31:04 | braewoods | this is all for my ZIP stuff and it's only used temporarily so not a permanent reservation |
| 11:31:16 | braewoods | i'm also reusing buffers once they're done with their original purpose |
| 11:31:53 | braewoods | for my ZIP support i decided to split my code into 3 phases... |
| 11:32:23 | braewoods | seeks can be expensive when you're jumping all over the file so i decided to cache the data i need from the CD in one read pass so i won't need to seek back to do it while i'm processing the actual file data |
| 11:32:36 | f1refly | i wrote the logic to reuse a partially read buffers content last week, avoiding it seems like a logical choice to me :) |
| 11:32:55 | braewoods | ah, just a habit i developed from learning about parsers. |
| 11:32:58 | f1refly | that seems very reasonable |
| 11:33:18 | braewoods | i'm trying to decide how to utilize the memory best |
| 11:33:28 | braewoods | and caching small data so i don't need to seek back to it is a good use for it |
| 11:33:42 | braewoods | that probably will kill the ZIP performance more than anything |
| 11:33:53 | f1refly | yes, it is |
| 11:34:29 | braewoods | i actually deployed a stripped down version of the CD because it has a lot of fields i don't actually need because the LF header has most of it |
| 11:34:31 | f1refly | how are you going to manage what you keep at what place? |
| 11:34:33 | braewoods | it's a duplicate |
| 11:34:41 | f1refly | are you doing that centrally or where you use it? |
| 11:34:49 | braewoods | what do you mean? |
| 11:34:52 | braewoods | the memory allocation? |
| 11:35:24 | braewoods | i'm taking a large memory chunk the the user of the ZIP code provides so i don't need to deal with how it should be allocated |
| 11:35:39 | braewoods | instead i just chunk up the memory chunk they give me to allocate memory for my ZIP code |
| 11:35:52 | braewoods | kinda like the function stack |
| 11:36:15 | braewoods | it also allows me to dynamically use it so smaller entries don't use as much space |
| 11:36:34 | braewoods | and i don't need to pay the regular price that usually comes with dynamic memory allocations |
| 11:37:25 | f1refly | so you're putting tiny parts into your big allocated buffer, right? |
| 11:37:35 | f1refly | or am i just too dumb to get it right now? |
| 11:37:43 | braewoods | well let me show my code so far |
| 11:38:07 | braewoods | it's not ready to be staged into rockbox but this is what i have |
| 11:38:30 | braewoods | braewoods/rockbox/blob/microzip/firmware/common/zip.c">https://github.com/braewoods/rockbox/blob/microzip/firmware/common/zip.c |
| 11:38:41 | braewoods | i start from the point of when the zip handle is first opened |
| 11:38:44 | * | f1refly is clocking out of work for the day |
| 11:39:19 | braewoods | i try to get an aligned pointer from the provided buffer |
| 11:39:29 | braewoods | i assign that for the zip handle's own stuff |
| 11:39:52 | braewoods | then i store the pointer to the remainder of the chunk for future allocations in the handle itself |
| 11:40:06 | braewoods | checking if there's enough space remaining each time i need to use it |
| 11:41:17 | braewoods | i thought it best to do this so i can minimize the cost and space waste normally associated with dynamic memory management |
| 11:41:30 | braewoods | it also allows me to work with more kinds of memory buffers |
| 11:41:52 | braewoods | since i'm planning for this to be usable in bootloaders and rockbox core |
| 11:42:25 | braewoods | i'm read a lot about memory management techniques but this is honestly my first time actually trying it for myself |
| 11:42:49 | braewoods | i normally just use malloc and call it a day |
| 11:43:08 | braewoods | but the overhead it has makes me want to roll my own in this case |
| 11:43:18 | braewoods | since rockbox has limited memory and cpu resources |
| 11:43:24 | f1refly | give me a few minutes more to read into your file |
| 11:45:10 | braewoods | most of my use of it doesn't need aligned access but some of it does |
| 11:45:36 | braewoods | note it's still under development |
| 11:45:47 | braewoods | this is like my third overhaul as i got ideas for how to improve i |
| 11:45:50 | braewoods | it |
| 11:45:58 | braewoods | think this is my last major revision |
| 11:46:16 | braewoods | i decided i needed to more intelligently use my RAM buffers |
| 11:46:32 | braewoods | instead of always using a fixed size like a moron... |
| 11:46:36 | braewoods | X) |
| 11:46:44 | braewoods | if this was a PC i'd do that just for simplicity but |
| 11:46:59 | braewoods | i don't have gigabytes of RAM or megabytes of stack space at my disposal |
| 11:47:24 | braewoods | i wanted to try to make this usable even on our lowest RAM target, around 2MB I believe |
| 11:47:41 | f1refly | I think i get it now |
| 11:47:44 | f1refly | looks pretty good |
| 11:48:06 | braewoods | f1refly: it's based on the same principle as stack allocations |
| 11:48:16 | f1refly | yes |
| 11:48:26 | f1refly | i only know in theory how that works |
| 11:48:30 | braewoods | which is the most efficient way to dynamically manage memory |
| 11:48:33 | f1refly | never had to implement something like it before |
| 11:48:35 | braewoods | but it comes with a cost |
| 11:48:38 | f1refly | but your implementatino looks good |
| 11:48:50 | braewoods | there's an upper limit on how much you can allocate with it |
| 11:49:03 | braewoods | but it's excellent way for dynamic allocations of temporary buffers or so |
| 11:49:17 | braewoods | after all in my use case all the permanent stuff is going to be handled by the user callback |
| 11:49:29 | braewoods | i just need to buffer it long enough for them to do their thing |
| 11:50:55 | f1refly | hmm |
| 11:51:12 | f1refly | can you recommend me a book where i can learn more? |
| 11:51:39 | f1refly | i develop c++ for a living but always wanted to learn more about c best practices |
| 12:00 |
| 12:18:42 | braewoods | f1refly: about memory management? |
| 12:25:46 | speachy | "let someone else do it" :D |
| 12:26:30 | braewoods | sometimes i think the most complex part of a libc is all the dynamic memory APIs. |
| 12:26:38 | braewoods | they all have to work together |
| 12:26:56 | speachy | threading |
| 12:27:00 | braewoods | malloc, calloc, aligned_alloc |
| 12:27:01 | speachy | that's the real mess. |
| 12:27:13 | braewoods | yea, and threading also plays a part since these have to be thread safe |
| 12:49:13 | | Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:8d8d:14e6:d447:3796) |
| 13:00 |
| 13:04:11 | *** | No seen item changed, no save performed. |
| 13:54:53 | | Quit advcomp2019 (Read error: Connection reset by peer) |
| 13:56:44 | | Join advcomp2019 [0] (~advcomp20@user/advcomp2019) |
| 15:00 |
| 15:04:12 | *** | Saving seen data "./dancer.seen" |
| 16:00 |
| 16:18:07 | | Quit lebellium (Quit: Leaving) |
| 16:28:42 | | Quit rb-bluebot (Ping timeout: 268 seconds) |
| 16:29:56 | | Quit bluebrother (Ping timeout: 268 seconds) |
| 16:31:36 | | Join bluebrother [0] (~dom@55d4dc16.access.ecotel.net) |
| 16:42:27 | | Join rb-bluebot [0] (~rb-bluebo@55d4dc16.access.ecotel.net) |
| 16:57:52 | _bilgus | braewoods, I'm a bit surprised the inbuilt buflib wasnt good enough TLSF |
| 16:59:48 | _bilgus | eh Two-Level Segregated Fit before you think its some weird turn of phrase :p |
| 17:00 |
| 17:00:52 | speachy | Thread-Local Storage? |
| 17:00:55 | speachy | heh |
| 17:04:13 | *** | Saving seen data "./dancer.seen" |
| 18:00 |
| 18:00:50 | | Quit akaWolf (Ping timeout: 252 seconds) |
| 18:33:39 | | Join akaWolf [0] (~akaWolf@akawolf.org) |
| 19:00 |
| 19:04:15 | *** | Saving seen data "./dancer.seen" |
| 19:59:24 | | Quit MarcAndersen (Read error: Connection reset by peer) |
| 21:00 |
| 21:04:18 | *** | Saving seen data "./dancer.seen" |
| 21:16:53 | | Join richbridger [0] (~richbridg@213-225-32-103.nat.highway.a1.net) |
| 21:18:01 | | Quit aquijoule_ (Read error: Connection reset by peer) |
| 21:30:12 | kirvesAxe | Uhh... any idea what could cause rockbox running on an AGPtek Rocker to refuse playing .ogg files under one directory tree, but playing other file types from there and all types of files from other directories without issues? :) |
| 21:31:57 | kirvesAxe | (this issue appeared after the latest "take the microsd card for a spin on the PC" phase) |
| 22:00 |
| 22:39:38 | | Quit amiconn (Quit: No Ping reply in 64 seconds.) |
| 22:40:11 | | Quit j-r (Ping timeout: 244 seconds) |
| 22:40:34 | | Join j-r [0] (~j-r@p2003000621560705404207fffefd0a65.dip0.t-ipconnect.de) |
| 22:40:47 | | Join amiconn [0] (jens@p200300ea8722b300305e95fffec66ff3.dip0.t-ipconnect.de) |
| 23:00 |
| 23:04:21 | *** | Saving seen data "./dancer.seen" |
| 23:10:50 | | Quit blbro[m] (Remote host closed the connection) |
| 23:10:53 | | Quit kadoban (Read error: Connection reset by peer) |
| 23:11:53 | | Join kadoban [0] (~kadoban@user/kadoban) |
| 23:18:00 | | Join blbro[m] [0] (~blbrostra@2001:470:69fc:105::8f7) |
| 23:29:15 | | Join mendel_munkis [0] (~mendel_mu@ool-ae2cb218.dyn.optonline.net) |
| 23:31:10 | | Quit munkis (Ping timeout: 258 seconds) |
| 23:31:51 | | Nick mendel_munkis is now known as munkis (~mendel_mu@ool-ae2cb218.dyn.optonline.net) |
| 23:33:08 | | Quit kadoban (Quit: node-irc says goodbye) |
| 23:43:22 | | Quit blbro[m] (Quit: node-irc says goodbye) |
icon identifies that the person is a core developer (has commit access).