uBASIC speed optimizations (topic split from another thread) - page 2 - General Discussion and Assistance - CHDK Forum

uBASIC speed optimizations (topic split from another thread)

  • 36 Replies
  • 6737 Views
Re: uBASIC speed optimizations (topic split from another thread)
« Reply #10 on: 10 / November / 2011, 08:40:55 »
Advertisements
And is anywhere exists SVN of SDM?
Now that's an interesting question ...
Ported :   A1200    SD940   G10    Powershot N    G16

Re: uBASIC speed optimizations (topic split from another thread)
« Reply #11 on: 10 / November / 2011, 08:48:15 »
If I was going to merge this, I'd rather not have unrelated ubasic optimizations in the same patch.
Regardless of the speed and optimization discussions,  it would be nice to see these changes include :

* Fixed bug: hanging-up if unknown token found in some places (in print statement for example)
  * Fixed bug: error "No label" if jump to the end

Quote
I'm not personally not inclined to expend much effort on ubasic, Lua is a far better language, and the effort to bring ubasic to anything close to that standard would be huge. Not performance , but things like multi-letter variable names, local variables, strings, tables, functions, file io...

That doesn't mean I won't apply improvements for ubasic, but if they take me a lot of work to understand and apply, that certainly won't count in their favor.
No argument here on the relative merits of Lua vs uBasic,  but the simple fact is that a lot more users have some Basic programming knowledge rather than Lua knowledge and most of the published scripts on the forum and Wiki are in uBasic.
Ported :   A1200    SD940   G10    Powershot N    G16

Re: uBASIC speed optimizations (topic split from another thread)
« Reply #12 on: 10 / November / 2011, 08:54:11 »
Regardless of the speed and optimization discussions,  it would be nice to see these changes include :

* Fixed bug: hanging-up if unknown token found in some places (in print statement for example)
* Fixed bug: error "No label" if jump to the end

I think I could isolate them too.

*

Offline reyalp

  • ******
  • 12159
Re: uBASIC speed optimizations (topic split from another thread)
« Reply #13 on: 21 / November / 2011, 18:45:39 »
edit: the final syntax ended up a bit different, see http://chdk.wikia.com/wiki/Script_commands#set_yield

After some thinking about this, I've concluded that yield behavior should be adjustable from script.

Rational:
  • Current behavior is acceptable for most scripts.
  • Impact of running lots of cycles in kbd_task is unclear, will vary depending what camera is doing.
  • 10ms precision of get_tick_count means that even the lowest setting is a drastic change in kbd_task behavior
  • The fact lua can run for excessive times is a bug. Better control of scheduling should be added to lua, rather than re-creating this in ubasic.
Conclusion:
Users who actually need extra speed should have direct control over scheduling, so they can determine the best balance of performance and potential side effects.

#3 unfortunately means that one, tick based setting is insufficient. Setting it to 0 could reproduce the current behavior, but you have nothing between 1 line per cycle (which should generally be a fraction of a ms) and noticeably slowing down kbd_task.

Solution:
Allow the user to set maximum lines before yield, and maximum execution time. Whichever one is hit first wins. Setting max lines to 1 reproduces current behavior. Setting either to an arbitrarily high number effectively disables the limit. This feels slightly overcomplicated, but I didn't see a clean way to do everything I wanted with less.

Patch in attached zip implements the above. The defaults reproduce the existing trunk behavior. The line and tick limits are treated as unsigned, so -1 can be used to set either or both "unlimited"

The test script allows you to try different values.  The "dummy" test script allows testing the equivalent script on builds that don't have the new commands (see note #1 below for why this is needed).

Test results for D10, 1000 iterations, playback mode, times in ms
old trunk (dummy script): 30020
tsvstar patch (dummy script): 3530
defaults: 30020
no yield (-1,-1), play: 3260

Notes
  • ubasic is brain damaged in many ways. In testing, I noticed that adding more @ directives and some simple assignments *outside* of the main loop of my test script increased the run time by a factor of ~2. This is because things that implicitly refer to a line number (like a while loop) get there by running the whole script through the tokenizer from the start (see jump_line)
  • runtime is different in play and rec mode
  • All of the above times are terrible compared to lua, where a similarly trivial loop is ~100x as fast with yields, and ~1000x without http://chdk.setepontos.com/index.php?topic=6729.msg71456#msg71456

I noticed tsvstars patch avoided calling get_tick_count each line. I haven't done this, because the call is quite cheap. Basically, it just disables interrupts, gets a variable, and restores interrupts. If you *really* want more performance out of ubasic, fixing things like the brain damaged mentioned above will be far more productive. Or just use lua...

tsvstars patch also didn't set the yield flag for MD, which would have broken MD scripts. I've added that in mine.
« Last Edit: 26 / November / 2011, 21:48:38 by reyalp »
Don't forget what the H stands for.



Re: uBASIC speed optimizations (topic split from another thread)
« Reply #15 on: 21 / November / 2011, 18:55:46 »
Notes
  • ubasic is brain damaged in many ways. In testing, I noticed that adding more @ directives and some simple assignments *outside* of the main loop of my test script increased the run time by a factor of ~2. This is because things that implicitly refer to a line number (like a while loop) get there by running the whole script through the tokenizer from the start (see jump_line)
  • runtime is different in play and rec mode
  • All of the above times are terrible compared to lua, where a similarly trivial loop is ~100x as fast with yields, and ~1000x without http://chdk.setepontos.com/index.php?topic=6729.msg71456#msg71456

Isn't some of this covered by tsvstar's other patches ? Specifically :

  * Parser optimized to be 4-6 times faster on first pass and 30-40 times faster(runtime compilation used) on next passes
  * Control flow operators are now zero-cost (do not parse script from begin each time). So now size and complexity of script has no matter
Ported :   A1200    SD940   G10    Powershot N    G16

Re: uBASIC speed optimizations (topic split from another thread)
« Reply #16 on: 21 / November / 2011, 18:59:31 »
And is anywhere exists SVN of SDM?
http://trac.assembla.com/chdkde/browser/branches/SDM
Very nice.   Although it all seems to be 4 months old.  Does that mean you do not build new releases from here ?
Ported :   A1200    SD940   G10    Powershot N    G16

Re: uBASIC speed optimizations (topic split from another thread)
« Reply #17 on: 21 / November / 2011, 19:12:07 »
<deleted - posted the wrong place>
« Last Edit: 21 / November / 2011, 19:13:47 by waterwingz »
Ported :   A1200    SD940   G10    Powershot N    G16


*

Offline reyalp

  • ******
  • 12159
Re: uBASIC speed optimizations (topic split from another thread)
« Reply #18 on: 21 / November / 2011, 19:44:37 »
Isn't some of this covered by tsvstar's other patches ? Specifically :

  * Parser optimized to be 4-6 times faster on first pass and 30-40 times faster(runtime compilation used) on next passes
  * Control flow operators are now zero-cost (do not parse script from begin each time). So now size and complexity of script has no matter
Sounds like it, I was only looking at the scheduling one and had already forgotten about all the earlier posts ;)
Don't forget what the H stands for.

Re: uBASIC speed optimizations (topic split from another thread)
« Reply #19 on: 22 / November / 2011, 06:17:26 »
url=http://trac.assembla.com/chdkde/browser/branches/SDM]http://trac.assembla.com/chdkde/browser/branches/SDM[/url]

Thanks

After some thinking about this, I've concluded that yield behavior should be adjustable from script.
I noticed tsvstars patch avoided calling get_tick_count each line. I haven't done this, because the call is quite cheap. Basically, it just disables interrupts, gets a variable, and restores interrupts. If you *really* want more performance out of ubasic, fixing things like the brain damaged mentioned above will be far more productive. Or just use lua...

tsvstars patch also didn't set the yield flag for MD, which would have broken MD scripts. I've added that in mine.
I think my full patch will solve this problem. And thanks for catch MD problem. I miss this implicit action call.
Below is my full patch adapted to 1420 and mixed up with your variant of scheduling control.

Unfortunatelly I can't test perfomance by myself  right now because my camera is in service.

 

Related Topics