Timeline for Recreating binary counter for arbitrary length arrays
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 10, 2020 at 13:24 | history | edited | CommunityBot |
Commonmark migration
|
|
| Jun 13, 2015 at 12:35 | comment | added | jacwah | @syb0rg The compiler could be optimizing tail recursion calls, which would explain why there is a very small difference in speed. This would also mean that new stack frames are not created for consecutive calls and no more memory is used than in an iterative solution. | |
| May 19, 2015 at 22:10 | comment | added | syb0rg | @MattBorja Even if you are finding your recursive solution to be faster (which seems odd to me), you should still remove it as recursion in principle requires a TON of stack space when compared to iterative versions. Since you are running on an embedded device, you'll definitely want to be as conservative as you can with your memory (as you already seem to be mindful of) and go ahead with the switch to an iterative solution. | |
| May 19, 2015 at 7:42 | comment | added | JS1 | @MattBorja Have you tried using an int or a long? You said you wanted to avoid long long but what about 32 bits at a time? | |
| May 19, 2015 at 6:43 | comment | added | Matt Borja | Yeah, it's in the ballpark at this point, definitely appreciable improvement. I'm just using github.com/Robot-Will/Stino for adding Arduino compiler to SublimeText as far as that goes. | |
| May 19, 2015 at 6:40 | comment | added | JS1 | @MattBorja Don't know what to say. On my x86 desktop it is faster than the recursive version (but I'm not sure what optimizations GCC is doing). I have no idea what compiler you are using for your Atmega328 or what code it is generating. | |
| May 19, 2015 at 6:38 | comment | added | Matt Borja |
269,366 inc/s, last count: 04 1C 36 - note I'm actually running this before any other tests now, which is seeing a slight improvement so your benchmark has been updated. Running the same test with the recursive version yields 274,006 inc/s, last count: 04 2E 56 with the highest recorded in the original post.
|
|
| May 19, 2015 at 6:22 | comment | added | JS1 | @MattBorja I modified the code, can you retest? I changed the loop to a do loop to move the end check to the bottom. | |
| May 19, 2015 at 6:20 | history | edited | JS1 | CC BY-SA 3.0 |
added 4 characters in body
|
| May 19, 2015 at 5:45 | comment | added | Matt Borja |
Yeah, the no check for end of array I simply didn't include in my code but did add it later. However, regarding simplification, I just did a quick 1s benchmark test between my function (recursive) and yours and got the following results: recursive: 273452 inc/s (incBytes), last count: 04 2C 2C vs. non-recursive: 244377 inc/s (incBytes2), last count: 03 BA 99. Does that sound right?
|
|
| May 19, 2015 at 0:58 | history | edited | JS1 | CC BY-SA 3.0 |
added 13 characters in body
|
| May 18, 2015 at 23:05 | history | answered | JS1 | CC BY-SA 3.0 |