What kind of optimizations does the Unicon compiler have?
> On Apr 11, 2017, at 12:26 AM, Don Ward <d...@careful.co.uk> wrote:
>
> 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
------------------------------------------------------------------------------
|
| "The belief that there is only one truth, and that oneself is in
| possession of it, is the root of all evil in the world." -- Max Born
|
| Dr. Robert Heckendorn
| hecke...@uidaho.edu
| http://marvin.cs.uidaho.edu/~heckendo
| Computer Science Dept, Univ. of Idaho, Moscow, Idaho, USA 83844-1010
------------------------------------------------------------------------------
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
