Again close to half of the time is spent copying arrays prior to alteration, but I've discussed this at length already.
Now, there is a way to improve the performance of the array copying. I think there might be an opportunity to shave some 20% off the execution time by implementing support for pure arrays (i.e. depth-1 arrays where all cells are the same type. This is because there are virtual calls on the Values in the array that is being dispatched on, once per cell. For pure arrays, the type can be checked once at the beginning, the elements downcasted using reinterpret_cast<>, which will avoid the virtual call. I'm thinking that this could possibly be done simply by having an extra type indicator in the array class, that indicates if the array is pure, and if so, what type it contains. Thoughts? Regards, Elias On 10 September 2015 at 22:13, Mike Duvos <[email protected]> wrote: > The attached transfer file contains an implementation of the SHA-256 > message digest function, described in FIPS 180-4, as a collection of APL > objects. This is an excellent test of doing large numbers of single-bit > operations in APL. > > The function HASH computes the message digest of a character string using > SHA-256, and returns the result as a lower case hexadecimal character > string. > > HASH 'The Magic Words are Squeamish Ossifrage' > d85b3de57112eea32ab96a7ba6f828f7bb2e49df245be23acbc5609d0eec7939 > > We can hash something a bit longer, and time it, first in APL2 on my Dell > Dimension 2400. > > [IBM APL2] > > TIME 'HASH 10000⍴''X''' > 94a4ce4b205554d83c065a65cfd0590f488c78004895342afe913c94a7287db1 > 2.797 Seconds. > > And next in GNU APL on my Amazon instance of Ubuntu Server, again with > instrumentation disabled. > > [GNU APL] > > TIME 'HASH 10000⍴''X''' > 94a4ce4b205554d83c065a65cfd0590f488c78004895342afe913c94a7287db1 > 2.481 Seconds. > > So this is another example of a calculation where GNU APL is quite > competitive with IBM's APL2 product. > > >
