In my quick test, I tried putting a use [a b c d e] block around the second loop. But it didn't seem to make any difference. I would suggest a function that returns some composed code to do, to optimise.
Also, I'd like to complain ;) about the style below, (which is not quite style-guide compliant). If I paste this code straight into the console, it fails on the first line because func is expecting a block, but a newline indicated that the expression was finished and the console should do it. (Not to single you out Joel, some others here are guilty too. ;) It is a very small thing compared to the content...) Regards, Anton. > setter: func > [ n [integer!] m [integer!] > /local a b c d e f t0 t1 t2 > ][ t1: 0 a: 1 b: c: d: e: f: 0 > loop m > [ t0: now/time/precise > loop n > [ f: e e: d d: c c: b b: a a: f] > t1: t1 + now/time/precise - t0 > ] > t2: 0 a: 1 b: c: d: e: f: 0 > loop m > [ t0: now/time/precise > loop n > [ set [a b c d e] reduce [b c d e a]] > t2: t2 + now/time/precise - t0 > ] > print [t1 t2] > ] > > I was *quite* surprised by the results: > > >> setter 1000 1000 => 0:00:08.69 0:00:41.29 4.75143843498274 > >> setter 1000 2000 => 0:00:17.5 0:01:22.91 4.73771428571429 > >> setter 2000 1000 => 0:00:16.93 0:01:21.95 4.84051978735972 > >> setter 2000 2000 => 0:00:33.03 0:02:46.65 5.04541326067212 > > (This was performed on a 'doze box, so subsecond details are > dubious at best...) > > Notice that the block SET takes about 5 times as long as the > serial version, with the cost rising slowly as the number of > iterations increases. This suggests to me that the overhead > is related to the memory management involved in constructing > (large numbers of) temporary blocks. > > > I be interested in whether there's any other way to get the > same result without so much overhead (or whether I've overlooked > anything in the above test). > > -jn- -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
