David,
There's no manual way to make x[y] not allocate a trapped variable. Some things
that allocate trapped variables have alternative forms of access (for example,
function calls) that are cheaper, but others do not.
Wall clock time is wall clock time. If it is faster it is faster, even if it
has more collections.
Failing silently is not supposed to happen, so it is not obvious what to tell
you to do to catch it. We welcome sample programs with instructions on how to
make them crash. C programmers have measures they can take to help us hunt bugs
in the runtime system if you can't share the program and problem reproducibly.
I could e-mail with you offline about that.
Cheers,
Clint
________________________________
From: David Gamey <david.ga...@rogers.com>
I didn't even know about trapped variables. I assume there is no manual way to
facilitate this. Like de-referencing it? Not as elegant as it figuring it out
by itself but useful.
I also assume that differences in &time include collection time. So if the
time is still faster with collections, it should still makes sense to use that
variant.
However, I think I tried 10^11 iterations and the program looked like it
terminated silently which will be a problem. Anyway I can find out why?
I don't need to use rand as that was just for simulation. Just process digits
from lots of files. I got curious how much variation there might be in speed.
I didn't expect the collections.
Guess I should stop picking at threads in sweaters too. :)
David
________________________________
From: "Jeffery, Clint (jeffe...@uidaho.edu)" <jeffe...@uidaho.edu>
To: Unicon Group <unicon-group@lists.sourceforge.net>; David Gamey
<david.ga...@rogers.com>
Sent: Monday, April 10, 2017 10:14 PM
Subject: Re: [Unicon-group] Unexpected garbage collections
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_______________________________________________
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<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
