Clint,
Sadly for this, I would not be a good choice for C legacy code in a translator.
Assembler yes. C no.
David
From: "Jeffery, Clint (jeffe...@uidaho.edu)" <jeffe...@uidaho.edu>
To: Don Ward <d...@careful.co.uk>
Cc: David Gamey <david.ga...@rogers.com>; Unicon Group
<unicon-group@lists.sourceforge.net>
Sent: Tuesday, April 11, 2017 9:59 AM
Subject: Re: [Unicon-group] Unexpected garbage collections
#yiv2960502023 #yiv2960502023 -- P
{margin-top:0;margin-bottom:0;}#yiv2960502023 Don: the compiler is as clever as
you make it, but it cannot optimize away the trapped variables that areimplicit
side effects of various VM instructions that it generates. It needs the
cooperation of the VM inthe 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)
<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,ClintFrom: 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
ThanksDavid
------------------------------------------------------------------------------
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
------------------------------------------------------------------------------
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
