uBASIC speed optimizations (topic split from another thread)

reyalp

13716

Re: uBASIC speed optimizations (topic split from another thread)

« Reply #30 on: 25 / November / 2011, 01:08:44 »

Advertisements

Thanks for the detailed response.

I still don't understand why you put all this effort into ubasic. Do you have an actual need for ubasic to be this fast ? What kind of script would you write that needs this ? Especially in ubasic which is limited in so many other ways ? Why not use lua ?

If there is a real need, I am more willing to spend time on it. If it's just cool to make it faster, it seems like a waste of time.

Most CHDK scripts are a simple loop, some calculation, some shooting. Shooting takes most of the time. The old 10ms per line was not a big problem in most cases. In lua you can do some other things with files or strings, but ubasic doesn't have these anyway.

edit:
If other ubasic users want to test tsvstars patch, or feel this kind of optimization would benefit their script, please speak up

« Last Edit: 25 / November / 2011, 02:07:40 by reyalp »

Logged

Don't forget what the H stands for.

tsvstar

Re: uBASIC speed optimizations (topic split from another thread)

« Reply #31 on: 25 / November / 2011, 03:14:00 »

I see. And I do agree that for common usage yield is enough.

Why did I propose this improvement:
1. My final goal is customizable by text config-file menu. Its action will be based on scripts.
One of kind of element is "mode" (like "landscape", "night sport shooting", ...). It also based on script (camera/chdk parameters are adjusted to match condition).
First, it is good to execute it as quick as in-build GUI.
Second, one of planed thing (but for now I'm not sure that I will implement) is simple event (1sec_tick or mode_dial_change) in this mode. And so script should be in-memory and work really fast. No big functionality required. I'm able to implement this for ubasic (it simple) but LUA implementation is too big and entangleous for me + almost take additional ~100Kb
For example, check if brightness is too low - display proposition to turn on flash. Logic separated to script. This is not for advanced users - this is for blondies. I still can't explain to my wife when she should do what - so I will delegate this function to camera.

2. Some already existed scripts on forum are contain remark "do not write remarks below because perfomance degradate a lot".

Why I propose my way:
1. It already finished and stable.
2. It quick even on first pass
3. One thing based on another. I can't separate goto/gosub because it use precompilation. Precompilation is quick because rearanged code of parser.

I'm open to be declined. Then I just include this thing into my branch.
Anyway other ready changes change CHDK much more then this isolated change: almost ready binary modules, GUI improvements, AutoISO improvements. So they should be in experimental branch/fork first.

« Last Edit: 25 / November / 2011, 03:24:00 by tsvstar »

Logged

philmoz

3411

Re: uBASIC speed optimizations (topic split from another thread)

« Reply #32 on: 25 / November / 2011, 04:30:16 »

I think this is probably worth implementing - it doesn't seem to break anything that I've tried so far.
Although uBasic is not the nicest language it is simple and easy to learn and there are a lot of existing scripts that use it. While the performance optimisations may not be visible to the user, if the code is using less CPU cycles then that has to be a benefit all round.

I'd like to see more comments in the code to help explain what the changes are doing - for the next generation of CHDK coders who inherit this stuff

I also agree with reyalp about the magic numbers - I think it would be better to have the special token values as #define values rather than 0x1, 0x2, etc.

Lastly the changes increase the CHDK compiled code size by ~1.3K - not a huge amount; but a number of older cameras are very memory limited so any increase can be a problem. This isn't a show stopper; but if there are any ways to optimise the code size as well that would help.

Phil.

Logged

CHDK ports:
sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
g12 (1.00c, 1.00e, 1.00f & 1.00g)
sx130is (1.01d & 1.01f)
ixus310hs (1.00a & 1.01a)
sx40hs (1.00d, 1.00g & 1.00i)
g1x (1.00e, 1.00f & 1.00g)
g5x (1.00c, 1.01a, 1.01b)
g7x2 (1.01a, 1.01b, 1.10b)

Microfunguy

4037

Re: uBASIC speed optimizations (topic split from another thread)

« Reply #33 on: 25 / November / 2011, 05:35:13 »

Just curious, what practical application requires uBasic or Lua to be fast ?

Logged

tsvstar

Re: uBASIC speed optimizations (topic split from another thread)

« Reply #34 on: 25 / November / 2011, 06:06:33 »

Quote from: Microfunguy on 25 / November / 2011, 05:35:13

Just curious, what practical application requires uBasic or Lua to be fast ?

1. I did describe what is for I prepared this changes.
2. Sometimes it shouldn't be fast - it should be not too slow.

For example, "Selective Intervalometer" by SkyWalker9 contain
rem -- Do not add comments after this point ---
I suspect to fast enough responsivness and to good enough perfomance to shots with seconds precisions.
Script nice and author have no skill to write it on LUA.

Quote from: philmoz on 25 / November / 2011, 04:30:16

I also agree with reyalp about the magic numbers - I think it would be better to have the special token values as #define values rather than 0x1, 0x2, etc.

Lastly the changes increase the CHDK compiled code size by ~1.3K

I do agree that replacing magic numbers increase code self-documentation. Will fix.
On my gcc4.5.1 difference is only 0.8K.

Logged

Microfunguy

4037

Re: uBASIC speed optimizations (topic split from another thread)

« Reply #35 on: 25 / November / 2011, 08:12:52 »

Quote from: tsvstar on 25 / November / 2011, 06:06:33

1. I did describe what is for I prepared this changes.

If I understand correctly, I implement the first feature in a private build.
It is just filling-in a form, it did not need to be fast.

As far as the second feature is concerned, are you saying the Canon Auto and optional Scene modes are not simple enough ?

I am not trying to put you off, I just want to understand what you think Canon have overlooked for the point-and-shooters.

Logged

tsvstar

Re: uBASIC speed optimizations (topic split from another thread)

« Reply #36 on: 25 / November / 2011, 09:15:33 »

"First" is call specified in config file script when I select menu item. (So I customize just in text content of menu and assign action scripts to specific item). Most items are reconfigure camera and chdk settings. I do not agree with many built-in rules of camera, because can make better shot based on different set of rules.
Why quick ubasic. I suspect that such scripts could be big and/or complex. And I hate any lags when do something in GUI.

"Second" is some text tips which script say based on tracking for condition. This will be done by same script.
For example, I often forget to do something. Basic users even don't know many simple rule like "use flash if counterlight" and know nothing about iso-etc.

Logged