Good afternoon David,
I suspect that my earlier response will apply to both random and subsc
operations as you are using string and table and both will use trapped
variables.
regards
Bruce Rennie
On 11/04/17 11:49, David Gamey wrote:
> An update
>
> My spidey senses were way off.
>
> Just running every vs while with no do produced zero collections. I
> replaced the call with
>
> every !N do T_Digits["2"]
>
> And the collections dropped to half. So the ?S_digits is a culprit.
> Wonder where the other half are from.
> David
>
> ------------------------------------------------------------------------
> *From:* David Gamey <david.ga...@rogers.com>
> *To:* Unicon Group <unicon-group@lists.sourceforge.net>
> *Sent:* Monday, April 10, 2017 9:27 PM
> *Subject:* [Unicon-group] Unexpected garbage collections
>
> 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
> <mailto: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
------------------------------------------------------------------------------
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
