That’s super interesting to have such a small example that reproduces this problem.
I’ll try to find out what is going on here.
Thanks!
Interestingly, this happens only with a few commands (basically those without parameters ?).
For instance, replacing sqrt by pow 2 gives the same result for both constructs.
By the way, on my Mac “sqr” delivers a factor of nearly 2, “sqrt” one of 1.5 and as you state “pow 2” one nearly 1, similar to “sin” or “tan”!
Still in all cases “image plus inplace calculation” is always more efficient compared to “plus calculation”!
Actually, these problems have been around since I started asking about curves… I just chose the faster methods and forgot about it! Sorry about that! Glad @garagecoder unearthed it again. As you know, my machine is very sensitive to slowdowns - ha ha.
I’m currently investigating, and this is really weird. I cannot explain it.
1 Like
OK so I’ve found some issues for a few ‘arithmetic’ commands without arguments (as sqrt, sqr, cos, …), and hopefully fixed them.
Commits:
https://github.com/dtschump/gmic/commit/e96cddea31ad5bbc992693d48f4f86e6c89ac4c7
and
Now, with the latest gmic binary compiled a few minutes ago:
foo :
sp leaf r 1920,1080,1,3
tic repeat 50 { +sqr[0] rm. } toc
tic repeat 50 { [0] sqr. rm. } toc
rm
then:
[gmic]-0./ Start G'MIC interpreter.
[gmic]-1./foo/ Elapsed time: 0.311 s.
[gmic]-1./foo/ Elapsed time: 0.302 s.
[gmic]-0./ End G'MIC interpreter.
So, that is better (even if the +command is still a slightly bit slower).
I’ll continue to investigate.
1 Like
Not true in fact, when I swap the two lines, the first one is always a bit slower.
Must be related to some CPU wizardry 
That was one line of thought I had - with threading and jit I’m never quite sure when it’s something being unexpectedly slow, or optimisation. Sometimes it’s the opposite and something got faster! Plus the fact perf testing can be quite difficult to nail down in a way which makes it a fair test.
My current (casual) test method is to make the command as short as possible, no verbosity, iterate it and have a cool off period and a couple of general commands beforehand to reset the CPU/GPU. Maybe it is just black magic superstition but it seems to make readouts a little more consistent.
2 Likes
G’MIC doesn’t use the GPU. That would be awesome though. It would really speed up filters like the Popcorn Fractal or Thorn Fractal.
Feature Request: Could we have something like return(var) for math parser? What this does is return var at pixel x,y,z in the math parser or return the var.
Could you be more precise ? I don’t get how the value would be returned.
Something like this:
5,5,1,1,"if(x==1&&y==1,return(-1););k=sqr(x-3);q=sqr(y-3);sum(k,q);"
When x and y is at 1, it’ll be -1. Otherwise, it’ll be sum(k,q).
That seems a bit complicated to me.
Why not using:
5,5,1,1,"(x==1 && y==1) ? -1 : (k = sqr(x - 3); q = sqr(y - 3); sum(k,q));"
?
To avoid adding more spaces/tabs for long list of code would be the usage of it as all you need to do is to add a single if on top of long list of code rather than using if else to get the same result. Personally, not really a big deal though.
The following alternative allows to ‘break’ the evaluation at some point, but you have to take care that the return value must be set in a variable:
5,5,1,1,"(x==1 && y==1) ? (ret = -1; break());
k = sqr(x - 3); q = sqr(y - 3); ret = sum(k,q);"
Edit: More details.
Any expression in fill returns its result in the same memory slot for all pixels. This memory slot is defined by the last line of the expression.
In the expression above, we tell that the value must be always put in the memory slot that corresponds to the variable named ret.
This way, when x==y==1, we just have to set the value in ret to -1 and break the current evaluation for this particular pixel. The returned value will be always ret in this expression.
1 Like
It’s definitely not as simple as “G’MIC could use the GPU”.
Indeed, unless the entire image processing pipeline can be executed on a GPU, doing GPU calculation becomes not that interesting in the general case because of the required transfers between the memory used by the CPU and the GPU, that is a known bottleneck.
For a G’MIC pipeline, it’s obviously not possible to ensure any full image pipeline would run on the GPU.
It’s certainly a lot better with the latest build. Still some strange speed difference with the [0]x2 shortcut compared to [0] [0]. None of this really affects me, it’s just an observation.
That is strange.
I’ve tested that:
foo :
sp leaf r 1920,1080,1,3
tic repeat 50 { [0]x2 rm[-2,-1] } toc
tic repeat 50 { [0] [0] rm[-2,-1] } toc
rm
and I get consistent result (the syntax [0]x2 being even slightly faster in practice):
$ gmic foo
[gmic]-0./ Start G'MIC interpreter.
[gmic]-1./foo/ Elapsed time: 1.085 s.
[gmic]-1./foo/ Elapsed time: 1.094 s.
[gmic]-0./ End G'MIC interpreter.
What do you get @garagecoder ?
This really is inexplicable, I tested the above now and get pretty much what you did. All looks fine.
Perhaps something used cpu on my system at the time. I’ll be more careful with my tests before reporting anything more!
Mine are
[gmic]-1./foo/ Elapsed time: 1.823 s.
[gmic]-1./foo/ Elapsed time: 1.815 s.
1.8XX s each time: either can be faster.