Just a thought: Is the compiler clever enough to optimise away the trapped
variable? It has enough information in principle.
> On 11 Apr 2017, at 03:14, Jeffery, Clint (jeffe...@uidaho.edu)
> <jeffe...@uidaho.edu> wrote:
>
> Hi David,
>
> Good catch, you have bumped into one of my pet peeves.
>
> Generators are often slower than non-generators, but not because of (or
> causing of) garbage collections, particularly -- they do their magic on the
> stack, not on the heaps.
>
> Bruce is right, several Icon functions and operators such as x[y] allocate
> "trapped variables" just in case the surrounding code might want to assign to
> it. But in many applications, structures are read from over and over and the
> trapped variables are avoidable.
>
> On my todo-list and the Unicon help wanted list for several years now is: add
> another virtual machine instruction for x[y] when the surrounding syntax
> guarantees that it will not be assigned to, in which case the underlying code
> can avoid the heap allocation. It is non-trivial enough that it won't get
> done on its own, someone has to volunteer, or someone has to commit some
> resources to it. I might do it myself if ever it makes it to the top of my
> priority list.
>
> Cheers,
> Clint
> From: David Gamey <david.ga...@rogers.com>
> Sent: Monday, April 10, 2017 6:49:28 PM
> To: David Gamey; Unicon Group
> Subject: Re: [Unicon-group] Unexpected garbage collections
>
> 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
> <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
> <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
