<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>Did you measure the improvements on real data? Are you allowed to share with the world? -- Matthias</div><div><br></div><div><br></div><br><div><div>On Dec 4, 2009, at 7:49 PM, Doug Williams wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Matthew,<br><br>I have updated several of the more computationally expensive components of the science collection (e.g., Chebyshev approximations (which are used in implementing many of the special functions), ordinary differential equation solving (which is used in the simulation collection for continuous models), and the statistics routines) to use the new unsafe operations. This does not include the flvector operations, which I haven't played with yet. The flvector operations should be easy to incorporate because I abstracted the sequence operators into a dispatching version of the for and for/fold macros that generate loops for lists and vectors as well as general sequences. I can just add another case to the dispatching macros for flvectors.<br>
<br>The question is to what extent you guys as the development team still consider these as experimental features. I have the code pretty well protected against crashes from the unsafe operations. I would like to release the updated science collection that uses them. But, if you think they aren't ready, I'll hold off. I use them myself now without any particular problems.<br>
<br>Doug<br><br><div class="gmail_quote">On Fri, Dec 4, 2009 at 2:47 PM, Matthew Flatt <span dir="ltr">&lt;<a href="mailto:mflatt@cs.utah.edu">mflatt@cs.utah.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">At Mon, 30 Nov 2009 21:48:45 -0500, Sam TH wrote:<br>
&gt; On Mon, Nov 30, 2009 at 9:34 PM, Matthew Flatt &lt;<a href="mailto:mflatt@cs.utah.edu">mflatt@cs.utah.edu</a>&gt; wrote:<br>
&gt; &gt; At Mon, 30 Nov 2009 21:29:07 -0500, Eli Barzilay wrote:<br>
&gt; &gt;&gt; [Matthew]<br>
&gt; &gt;&gt; * scheme/unsafe/ops? (wasn't mentioned last time)<br>
&gt; &gt;<br>
&gt; &gt; I don't think any of these need to be in the release announcement.<br>
&gt;<br>
&gt; It seems like the unsafe operations are now a significant part of the<br>
&gt; performance model, but they've never been announced more widely than<br>
&gt; the mailing list. &nbsp;Are we waiting for something?<br>
<br>
</div>I think we're waiting until we've figured out how to use it well enough<br>
or packaged it better for a wide audience.<br>
<br>
The problem with local bindings that Will Farr pointed out is a good<br>
example of where support for unsafe operations needs improvement.<br>
Another good example is an experiment that I committed yesterday (which<br>
I know that you noticed): there's now an `flvector' type that avoids<br>
the two extra indirections of an `f64vector' in unsafe mode. The<br>
`flvector' operations are also inlined better in safe mode. But<br>
`flvector' works less well for FFI interactions, the safe operations<br>
are typically less efficient than safe operations on plain vectors, and<br>
even the unsafe operations offer a benefit only when combined with<br>
other operations to avoid unboxing.<br>
<div><div></div><div class="h5"><br>
_________________________________________________<br>
&nbsp;For list-related administrative tasks:<br>
&nbsp;<a href="http://list.cs.brown.edu/mailman/listinfo/plt-dev" target="_blank">http://list.cs.brown.edu/mailman/listinfo/plt-dev</a><br>
</div></div></blockquote></div><br><input id="gwProxy" type="hidden"><input onclick="jsCall();" id="jsProxy" type="hidden"><div id="refHTML"></div>
_________________________________________________<br> &nbsp;For list-related administrative tasks:<br> &nbsp;<a href="http://list.cs.brown.edu/mailman/listinfo/plt-dev">http://list.cs.brown.edu/mailman/listinfo/plt-dev</a><br></blockquote></div><br></body></html>