On Mon, 5 Oct 2009, Loic Kessous wrote:
thanks Mathieu, it is still not clear for me what make things faster in one case or another but it helps.
cache has to load lots of data, because it assumes that the data is not very fragmented. Pd in 64-bit mode spends half of the argv space on padding. Here by spacing I mean the difference of starting position of two elements next to each other (e.g. where are $1 and $2 in RAM).
as data spacing. Pd in in any mode spends half of the nonpadding argv space on type information.
indeed a float, you need to use twice more data, and it's twice more spacing, but on top of that you need one conditional per element, just in case it isn't a float, and conditionals are getting comparatively slow on modern CPUs because they're harder to accelerate than the rest.
things in the cache more often, if the CPU's other tasks need the same cache for other purposes between the processing of two blocks. Bigger blocks mean that the CPU can "concentrate". Having to repeatedly call, init, deinit, return, is also something that can take time.
make the cache completely useless. it's better to do as many things as possible on a small area of RAM at a time.
Based on those five criteria, we could compare various storage and computation strategies of various internals and externals of pd, provided that we get a bit more precise on some things. There may also be additional criteria.
loic PS: what do you call Martin's strings ?
I thought I knew, but I borked that. Martin's strings are [mrpeach/str], but they don't use pd lists of floats, they use a custom atom type called BLOB, which is essentially a form of double-indirection. (POINTER is also a double-indirection, but it was meant for DS, though it's often hijacked to be used in other ways.)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801