Le 2011-11-23 à 00:16:00, Matteo Sisti Sette a écrit :
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?
Both, but the speed ratio is often not as bad as the memory ratio... it depends.
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?
It depends on whether an algorithm really needs to write a copy of the image because it needs to keep reading the original image until the work is done.
It depends on whether it is assumed that the user wants to keep a copy of the original data to do something with it (or perhaps the algorithm has to assume that the original data _might_ have to be read).
It depends on whether the algorithm has to modify only a portion of a whole copy of an image.
Etc.
But usually, the problem is not that the memory copying takes longer, it might just be that it takes a too big percentage compared to other tasks.
There's also the problem that making copies takes more active RAM, which means that the SRAM has to be swapping, which means that the actual CPU work of copying is slowed down by having to use the DRAM. When you have something like 2 gigs of RAM, these days, it's DRAM, whereas the SRAM is a much faster memory put closer to the CPU, and which is only a few megs. There might also be several levels of SRAM with different speeds and sizes.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC