On Thu, Oct 14, 2010 at 5:57 PM, William Leslie < [email protected]> wrote:
> On 15 October 2010 06:53, Jonathan S. Shapiro <[email protected]> wrote: > > So first, I think this is the wrong way to prioritize as a matter of > > defaults, but second, I think I've already made it clear that no > either/or > > choice is actually required. The "stranded string" approach does all of > what > > you want and more. The O(log n) factor issue is more than compensated for > by > > the improvement in D-cache and D-TLB utilization. > > I wasn't sure you'd be willing to accept the overhead of the built-in > string type being a type-class / capsule / interface / whatever, or > that you would be comfortable with the default string data type being > a more complicated structure (ropes, indexed strings, strings with > extents, etc). If they are, the emphasis on the representation working > well for all situations is less important to me. If you don't have any > reservations about the extra overhead from that abstraction (compared > to their C equivalents), then I don't imagine anyone will. > I'm not entirely sure what overhead you are thinking about. What seems likely here (to me) is that inlining of the string access operators will interact with loop unrolling favorably, in such a way that the indirection overhead can be largely eliminated when that is important. This is especially true for the sequential access case. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
