I guess
1) Correct (no freezing) 2) Yes, the force is implied exactly everywhere, and 3) Something like 20% on a good CPU.
Please correct me if I would be wrong.
2016-06-10 10:46 GMT+08:00 Adam adam.mlmb@gmail.com:
Aha.
Brief Q:s:
- The force code is not blocking the thread scheduler, right - so the
lazy expression can do (thread-sleep! alot) without freezing the host, right?
The auto-forcing is universal, right?
Any guess about how much slower the generated code becomes, do you
think it's rather 20% or 400%?
I guess if on the C/assembly level the check is really simple, then agood CPU will be able to optimize through already-forced values via branch prediction so rather 20% .. ?
2016-06-10 10:40 GMT+08:00 Marc Feeley feeley@iro.umontreal.ca:
When using --enable-auto-force, it is OK for test1 to fail this way (because test1 introspects the structure of the generated code, and, unfortunately, using auto forcing changes the structure of the code).
Marc
On Jun 9, 2016, at 4:00 PM, Bradley Lucier lucier@math.purdue.edu
wrote:
I'm taking the liberty of adding the Gambit mail list to the CC, since
this may be of general interest.
"make check" fails after configuring with
./configure 'CC=/usr/local/gcc-6.1.0/bin/gcc -march=native'
'--enable-single-host' '--enable-multiple-versions' '--enable-shared' --enable-auto-forcing
"make -i check" (to ignore errors and continue) gives
------------ TEST 1 (debugging support)
LD_LIBRARY_PATH=../lib:../gsi:../gsc:/usr/local/Gambit/current/lib:/usr/local/netpbm10/lib:/usr/local/gcc-6.1.0/lib/: ../gsi/gsi -:~~bin=../bin,~~lib=../lib,~~include=../include -f debug.scm > test1.out
diff test1.ok test1.out && rm -f test1.out 81a82
#return(##cprc-if2 3) : ($code rte)
85a87
#return(##cprc-if3 3) : ($code rte)
108a111
#return(##cprc-cond-if 3) : ($code rte)
112a116
#return(##cprc-cond-or 3) : ($code rte)
117,120c121,126 < #return(##cprc-cond-send-red 3) : ($code rte pred) < #procedure(##cprc-cond-send-red 4) < #return(##cprc-cond-send-red 5) : ($code rte oper)
< #return(##cprc-cond-send-red 6) : ($code rte)
#return(##cprc-cond-send-red 3) : ($code rte) #return(##cprc-cond-send-red 4) : ($code rte pred) #return(##cprc-cond-send-red 5) : ($code rte pred) #procedure(##cprc-cond-send-red 6) #return(##cprc-cond-send-red 7) : ($code rte oper) #return(##cprc-cond-send-red 8) : ($code rte)
125,127c131,135 < #return(##cprc-cond-send-sub 3) : ($code rte pred) < #return(##cprc-cond-send-sub 4) : ($code rte oper)
< #return(##cprc-cond-send-sub 5) : ($code rte)
#return(##cprc-cond-send-sub 3) : ($code rte) #return(##cprc-cond-send-sub 4) : ($code rte pred) #return(##cprc-cond-send-sub 5) : ($code rte pred) #return(##cprc-cond-send-sub 6) : ($code rte oper) #return(##cprc-cond-send-sub 7) : ($code rte)
131a140
#return(##cprc-or 3) : ($code rte)
135a145
#return(##cprc-and 3) : ($code rte)
140c150,151
< #return(##cprc-case 3) : (rte $code)
#return(##cprc-case 3) : ($code rte) #return(##cprc-case 4) : (rte $code)
250,251c261,263 < #procedure(##cprc-app0-red 3)
< #return(##cprc-app0-red 4) : ($code rte)
#return(##cprc-app0-red 3) : ($code rte) #procedure(##cprc-app0-red 4) #return(##cprc-app0-red 5) : ($code rte)
257,259c269,272 < #procedure(##cprc-app1-red 4) < #return(##cprc-app1-red 5) : ($code rte oper)
< #return(##cprc-app1-red 6) : ($code rte)
#return(##cprc-app1-red 4) : ($code rte oper) #procedure(##cprc-app1-red 5) #return(##cprc-app1-red 6) : ($code rte oper) #return(##cprc-app1-red 7) : ($code rte)
266,268c279,282 < #procedure(##cprc-app2-red 5) < #return(##cprc-app2-red 6) : ($code rte oper)
< #return(##cprc-app2-red 7) : ($code rte)
#return(##cprc-app2-red 5) : ($code rte oper arg1) #procedure(##cprc-app2-red 6) #return(##cprc-app2-red 7) : ($code rte oper) #return(##cprc-app2-red 8) : ($code rte)
276,278c290,293 < #procedure(##cprc-app3-red 6) < #return(##cprc-app3-red 7) : ($code rte oper)
< #return(##cprc-app3-red 8) : ($code rte)
#return(##cprc-app3-red 6) : ($code rte oper arg1 arg2) #procedure(##cprc-app3-red 7) #return(##cprc-app3-red 8) : ($code rte oper) #return(##cprc-app3-red 9) : ($code rte)
287,289c302,305 < #procedure(##cprc-app4-red 7) < #return(##cprc-app4-red 8) : ($code rte oper)
< #return(##cprc-app4-red 9) : ($code rte)
#return(##cprc-app4-red 7) : ($code rte oper arg1 arg2 arg3) #procedure(##cprc-app4-red 8) #return(##cprc-app4-red 9) : ($code rte oper) #return(##cprc-app4-red 10) : ($code rte)
297,298c313,315 < #procedure(##cprc-app-red 6)
< #return(##cprc-app-red 7) : ($code rte)
#return(##cprc-app-red 6) : ($code rte oper) #procedure(##cprc-app-red 7) #return(##cprc-app-red 8) : ($code rte)
303a321
#return(##cprc-app0-sub 4) : ($code rte)
310c328,329
< #return(##cprc-app1-sub 5) : ($code rte)
#return(##cprc-app1-sub 5) : ($code rte oper) #return(##cprc-app1-sub 6) : ($code rte)
317,318c336,338 < #return(##cprc-app2-sub 5) : ($code rte oper)
< #return(##cprc-app2-sub 6) : ($code rte)
#return(##cprc-app2-sub 5) : ($code rte oper arg1) #return(##cprc-app2-sub 6) : ($code rte oper) #return(##cprc-app2-sub 7) : ($code rte)
326,327c346,348 < #return(##cprc-app3-sub 6) : ($code rte oper)
< #return(##cprc-app3-sub 7) : ($code rte)
#return(##cprc-app3-sub 6) : ($code rte oper arg1 arg2) #return(##cprc-app3-sub 7) : ($code rte oper) #return(##cprc-app3-sub 8) : ($code rte)
336,337c357,359 < #return(##cprc-app4-sub 7) : ($code rte oper)
< #return(##cprc-app4-sub 8) : ($code rte)
#return(##cprc-app4-sub 7) : ($code rte oper arg1 arg2 arg3) #return(##cprc-app4-sub 8) : ($code rte oper) #return(##cprc-app4-sub 9) : ($code rte)
345,346c367,369 < #procedure(##cprc-app-sub 6)
< #return(##cprc-app-sub 7) : ($code rte)
#return(##cprc-app-sub 6) : ($code rte oper) #procedure(##cprc-app-sub 7) #return(##cprc-app-sub 8) : ($code rte)
makefile:113: recipe for target 'test1' failed make[1]: [test1] Error 1 (ignored)
I don't know whether this is important.
Brad
On 06/09/2016 02:11 PM, Mikael More wrote:
Awesomeness, thanks!!!!!
Fantastic, this means tight integration with a functional object database is possible.
I guess the expression code is running under the scheduler too, opening for storage of the database on non-low-latency facilities too, great!
2016-06-10 1:30 GMT+08:00 Bradley Lucier <lucier@math.purdue.edu mailto:lucier@math.purdue.edu>:
Try adding --enable-auto-forcing to your configure of Gambit.
On 06/09/2016 01:20 PM, Adam wrote:
Hi Marc! I have a practical question: I am thinking about the possibility of realizing a TIGHTLY integrated persistent object store ("object database"). (Tightly integrated, that is, with the Scheme heap.) The object store would be functional, so the host system cancache
object references as much as it wants. My question is: The best thing would be to 1) Have lazy loading of objects into the Scheme heap from the database (because the stored structures may have wather depth and shape meaning that precaching algorithms never would have an idea about what really needs to be loaded, so better let the code show that simply through what slots etc. it accesses), *AND* to at the same time 2) *NOT* need to customize the Scheme code for the lazy loading, i.e., have implicit |force| all over the code? A final wish here would be 3) The option that the |force| would be run as a procedure within the green threading system, so that other green threads wouldcontinue
executing while the lazy value is being loaded. Not sure about this one though - maybe for code-performance reasons it would be better to have it block. Even runtime procedures would need to do the implicit |force|. So the values that not are loaded right now, would be represented by a loading closure, and the result of closure invocation would be the value that should take the place of the respective accessed slot. Can this be done in Gambit, in its current form or with some very slight modification? Thanks!