Good afternoon David, I have just had a look through the latest (that I have) version of the Implementation Book and, if I have it right, the subscripting operation applied to the table in your every loop would appear to be allocating a trapped variable. If i understand this correctly, these trapped variables will be allocated in the block region and since you are doing this for every iteration, the number of allocations will be the same as the number of iterations. This should mean a significant number of garbage collections.
If I have got this wrong, Clinton and Jafar will be able to give you chapter and verse of the actual cause. So the best of both worlds might be to restrict yourself to using integer() as to speed and space optimisation. By the way, if permissible, what kind of problem are you dealing that requires trillions of operations? regards Bruce Rennie On 11/04/17 11:14, David Gamey wrote: > Hi folks, > > Over the years I've learned some interesting things about the garbage > collector and some builtin functions. Usually these show up because of > a combination of a badly understood choice and huge numbers of > iterations resulting an "interesting" if not pathological abuse of > memory. > > Once again I've stumbled upon what I think are unexpected garbage > collections and hoped for some insight. Some of this is just about > understanding how the garbage collector is working as much as it is > about if things could be made faster. > > I was looking at a problem that required trillions of operations so I > began looking at just how some of the basics performed. So I broke > down the problem into pieces and ran some benchmarks. > > This benchmark was to look at how single digit strings convert to > integers. So I thought of integer(x), ord(x)-48, Digits[x], > find(x,digits)-1 just to see what happens. Over several benchmarks > and magnitudes table is fastest, integer almost as fast, ord, the > find taking about 160% the time. > > I was surprised to see as many collections in flat code for a table > lookup. Now I know 192 collections for 10^8 operations isn't alot but > it's just a table lookup. > > * even ?S_digits causes about 1/2 the number of collections. But > why in the block region? > * The table lookup is actually fastest but it generates twice the > collections. > > > My spidey senses are telling me to try this without using every but > I'm just guessing. > > Here's the relevant code: > > procedure main(arglist) > > every (T_Digits := table())[d := !(S_Digits := > string(&digits))] := d > > O := options(copy(arglist),"-h!-N+-ON+") > N := \O["N"] | 10^\O["ON"] | stop("Usage: "||&progname||" [-N > itteration] [-ON itterationmagnitude]") > printf("\nBenchmarking with %d itterations\n",N) > printf("%s\n",&version) > > regionstat() > gcolstat() > t := &time # Start measurement > > /*_every !N do T_Digits[?S_Digits]_*/ > > printf("Execution time = %d\n",&time - t) # End > measurement > > gcolstat() > &dump := 1 > end > > And the output from running oddcollections.exe -ON 8 run on windows 10 > > Benchmarking with 100000000 itterations > Unicon Version 12.3. Feb 29, 2016 > ®ions {static, string, block} regions : 0, 41556459, 41556459 > &collections {heap, static, string, block} regions : 0, 0, 0, 0 > Execution time = 9386 > &collections {heap, static, string, block} regions : 192, 0, 0, 192 > > I also bench marked smaller units of code like every !N do ?S_Digits > > convertdigitsbench.exe -ON 10 > Benchmarking with 10000000000 itterations > ®ions {static, string, block} regions : 0, 41556459, 41556459 > &collections {heap, static, string, block} regions : 0, 0, 0, 0 > Time for 10000000000 itterations of procedure _S_Digits = > 551978 -- &collections {heap, static, string, block} regions : > 9634, 0, 0, 9633 > Time for 10000000000 itterations of procedure _T_Digits = > 764066 -- delta &collections {heap, static, string, block} regions > : 9634, 0, 0, 9633 > Time for 10000000000 itterations of procedure _integer = > 1065958 -- delta &collections {heap, static, string, block} > regions : 9634, 0, 0, 9633 > Time for 10000000000 itterations of procedure _ord = > 1191238 -- delta &collections {heap, static, string, block} > regions : 9634, 0, 0, 9633 > Time for 10000000000 itterations of procedure _ordconst = > 1149404 -- delta &collections {heap, static, string, block} > regions : 9634, 0, 0, 9633 > Time for 10000000000 itterations of procedure _table = > 1059456 -- delta &collections {heap, static, string, block} > regions : 19269, 0, 0, 19268 > T4 := table(0) > T4[procedure _S_Digits] := 551978 > T4[procedure _T_Digits] := 764066 > T4[procedure _integer] := 1065958 > T4[procedure _ord] := 1191238 > T4[procedure _ordconst] := 1149404 > T4[procedure _table] := 1059456 > &collections {heap, static, string, block} regions : 67439, 0, 0, > 67433 > > Thanks > David > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > Unicon-group mailing list > Unicon-group@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/unicon-group ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Unicon-group mailing list Unicon-group@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unicon-group