[Gridflow-dev] expr problem with '**'

[Mathieu Bouchard]

Le 2011-11-09 à 07:58:00, Jonathan Wilkes a écrit :

> I don't have my chat logs handy, but I remember you saying something 
> about a hypothetical [#expr~] or [#fexpr~] possibly being faster than 
> their counterparts.  Am I remembering that correctly?

Yes, but I can't tell you figures in advance.

Part of the slowness of [#expr] is because it uses code that was meant for 
mass computation, so every function that does every math operation in 
[#expr] checks how many pairs of values there are in every operation, and 
the number of pairs is always 1. In the case of [#expr~], there would be 
64 pairs (or whatever the block size is).

[expr~] probably already has such loops, though, so it's also possible 
that it won't be much faster, but something is sure : anything slow in the 
interpreter itself would be relatively less important in a context where 
things are done in chunks of 64 floats instead of chunks of just 1 float.

However, since then (later in the same day), [#expr]'s interpretation got 
much quicker, so, the proportions would be much different... and perhaps 
there would be a lot less improvement (or nearly none)... but I will not 
open [expr~]'s source to see.

[fexpr~] (and an hypothetical [#fexpr~]) are a different case, though. 
Their operations are not generally «vectorisable». This is why there is a 
distinction between that and the vectorisable [expr~]. It's because of the 
$y variables... cases in which they're not used can be fully vectorised 
(though I don't know whether this is currently done). cases in which $y 
appear are only partially vectorisable and only sometimes (e.g. if using 
only $y[-8] then you can compute everything in chunks of 8 instead of 1, 
which is a lot less than 64 but a lot more than 1).

  ______________________________________________________________________
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC