<div dir="ltr">Dear Marc,<div><br></div><div>Thank you very much for your clarification. Followup question below, to really understand what you are saying.</div><div class="gmail_extra"><br><div class="gmail_quote">2017-08-15 21:53 GMT+08:00 Marc Feeley <span dir="ltr"><<a href="mailto:feeley@iro.umontreal.ca" target="_blank">feeley@iro.umontreal.ca</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Jul 27, 2017, at 6:45 AM, Adam <<a href="mailto:adam.mlmb@gmail.com">adam.mlmb@gmail.com</a>> wrote:<br>
><br>
> I'll make closer benchmarking of auto forcing later, but, it incurs a quite steep overhead.<br>
<br>
</span>Experimental data please!<br></blockquote><div><br></div><div>I will provide it.</div><div>  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Meanwhile, I have a question:<br>
><br>
><br>
> With --enable-auto-forcing, at procedure calls, that is (procedure 'arg1 'arg2 'etc.), |procedure| is forced, as we can see by the example that in both interpreted and compiled mode, ((delay (begin (println "Forced.") (lambda (v) v))) #t) evaluates (and it prints out "Forced.").<br>
><br>
><br>
> I'd wildly guess that quite a lot of the overhead in auto-forcing is here. If you're sure the operator will never be a promise in any procedure call, then this particular aspect of auto forcing could be disabled.<br>
><br>
> (Without checking, I would guess that while Gambit may optimize so that local procedure calls may avoid being brought through the |force| logics, then, this optimization would do so that calls to procedures defined in *other* modules such as the runtime, would *not* be taken through |force| also. That should be positive for speed.)<br>
><br>
><br>
> Would it be possible for me to disable this particular aspect of the auto-forcing, to get higher performance?<br>
<br>
</span>Currently auto-forcing only works in interpreted code.  So if your program does (f x) and (car y) and you compile that, then “f” will not be forced and “y” will not be forced if car is inlined, for example if you (declare (not safe)).  You can consider this a bug… to be fixed.<br>
<br>
However, compiled predefined functions do the auto-forcing (when the system is configured with --enable-auto-forcing).  So (car y) will force y if the actual function is called, for example if you (declare (safe)), which is the default.<br>
<br>
Note that for “safe” compiled code, when compiling (f x) where f is a mutable global variable, it is necessary to generate a check that f is a procedure.  If it is not a procedure a handler is called that normally raises an exception.  This handler could easily be extended to first force the value and check if the resulting value is a procedure and proceed with the call if it is (hooray for raising exceptions in tail-position!).  So there would be no additional cost for safe compiled code.<br></blockquote><div><br></div><div>Can you please clarify what you mean here, by giving one or two pieces of example code, that illustrate the difference between various code operation options - so.. that would be</div><div><br></div><div>1) Interpreted code, vs.</div><div>2) Compiled code with (declare (safe)), vs.</div><div>3) Compiled code with (declare (not safe))</div><div><br></div><div>(I guess maybe (declare (block)) vs. (declare (separate)) could affect forcing behavior, as inlined code not would be forced, but non-inlined code could.)</div><div><br></div><div><br></div><div><br></div><div>In either case if I understand you right, there are examples where Gambit with auto-forcing enabled, will fail executing <font face="monospace, monospace">((delay (lambda () 'hello-world)))</font> .</div><div><br></div><div>Also.. if I understand you right, there are cases when Gambit with auto-forcing enabled also would fail evaluating <font face="monospace, monospace">(abs (delay 0))</font> .</div><div><br></div><div>Only for my clarity, please tell in what interval of conditions these will fail.</div><div><br></div><div><br></div><div>Thanks!</div></div></div></div>