So the problem is the underlying instruction set available to the compiler: got
it.
Another thought on David’s problem. Is this an Icon program or a Unicon
program? If the latter, would using an array instead of a table get around the
trapped variable allocation? If the look-ups really are just two character
strings, would it be possible to compute the index into the array from the two
characters and just return the appropriate array element?
Don
> On 11 Apr 2017, at 14:59, Jeffery, Clint (jeffe...@uidaho.edu)
> <jeffe...@uidaho.edu> wrote:
>
> Don: the compiler is as clever as you make it, but it cannot optimize away
> the trapped variables that are
> implicit side effects of various VM instructions that it generates. It needs
> the cooperation of the VM in
> the form of alternative instructions for known "read-only" uses of certain
> operators.
>
> David: you are right, the hard part is modifying the translator. It is
> under-documented legacy C code dating from around 1980.
> I have prototyped the adding of the virtual machine instruction in the VM
> before, it is not the problem.
> From: Don Ward <d...@careful.co.uk>
> Sent: Tuesday, April 11, 2017 12:26:07 AM
> To: Jeffery, Clint (jeffe...@uidaho.edu)
> Cc: Unicon Group; David Gamey
> Subject: Re: [Unicon-group] Unexpected garbage collections
>
> 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
>> <mailto:jeffe...@uidaho.edu>) <jeffe...@uidaho.edu
>> <mailto: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 <mailto: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 <mailto:david.ga...@rogers.com>>
>> To: Unicon Group <unicon-group@lists.sourceforge.net
>> <mailto: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://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://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
