Hey, thanks for the reply! On 11/22/2011 11:54 PM, Mathieu Bouchard wrote:
There's a problem with number types... the default number type has a lot more range than what is usually needed, and the other number types aren't so easy to use. If this were dealt with, the average GridFlow experience would be a lot faster.
Does that really have an impact on speed, not only memory usage?
Much of GridFlow is designed to be quite fast in an interpreted environment, by doing lots of work per message so that you don't need to send many messages, but it still is quite inefficient on certain things such as copying too much RAM.
I am curious about this in a general and OT way, because I've seen that happen in other interpreted environments and that sounds a lot counterintuitive to me (such in Processing, where the bottleneck is often in the methods that copy all the image pixels):
how comes that in those cases copying large amounts of memory is more of a bottleneck than actually doing computations?
Just a curiosity, and I understand that the question _may_ be badly formulated...
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
