[Gridflow-dev] expr problem with '**'
matju at artengine.ca
Wed Nov 9 11:54:43 EST 2011
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
More information about the Gridflow-dev