<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Maybe the issue of when "just in time" is. The JIT currently compiles<br>
at the granularity of `lambda', and it compiles each `lambda' only<br>
once. <br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
So, although `sequence-generate' may produce vector-specific operations<br>
for a given invocation of the `for' loop, the JIT produces a generic<br>
function call to the vector-specific operation (which might not be<br>
vector-specific next time around).<br></blockquote><div><br>So, the vector-specific lambda(s) returned by sequence-generate are optimized when they are first seen by the JIT compiler. But, there are additional optimizations (for the sequencing operation) that would not be possible within the for itself because there is not much left but generic function invocations. Specifically in the case of vectors, by having the for macro generate the increment and test of the index and the vector-refs, the JIT compiler can generate specific instructions for those operations. While, for a generic sequence that happens to be a vector, there is no alternative but to generate a call to see if more data is available and, if there is, another call to get the next element of the sequence.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
One possibility for improvement, then, is to change the JIT strategy to<br>
generate code later and more frequently.<br>
<div><div></div><div class="h5"><br></div></div></blockquote></div><br>But, writing some kind of 'dispatching for' macro is probably the only near-term way of getting nearly the same performance for a generic sequence that happens to be a vector and a 'for' specific written for a vector.<br>