On 17 March 2011 17:07, Ben Kloosterman <[email protected]> wrote: > Agree with you for the general case but looking at the specialist case - do > you think a bitc yacc or a bison will be of similar performance to c ?
I know too little about yacc implementation to be confident, and even then, it would mean nothing without actual measurement. To be honest, I don't even know what it does for strings internally. But here is what I *can* say. I think we have discovered two sources of potential overhead in an abstract, rope based default string implementation with linear iterators. One is that the check to determine the extents of the next character might not actually pay off relative to cache usage, which would be interesting to get some actual data on. Pypy can be convinced to use ropes internally, and I think there were slowdowns on some benchmarks, which is why the default build uses a standard byte array, but I don't know how closely the performance was analysed. I don't think the resulting iteration code was heavily optimised. The other is the indirection due to String becoming a typeclass. This means that some common functions won't be inlined, and some way of implementing the virtual dispatch needs to be present. It does mean, though, that strings do not always need to be converted from their source encoding. Sure, you could specify a concrete implementation as needed either to get inlining or particular performance characteristics, otherwise compared to flat UTF-32 you probably will see a drop in performance (how big?) on jobs like parsing, where you are usually dealing with at most a MB of small strings per process. On the other hand, any direct comparison will be complicated by the fact that you are in a higher-level language and can therefore focus on optimisations that knock an order of magnitude off operations rather than a small constant factor, so it should properly be compared to a yacc in *bitc* that uses flat strings internally. I would like to see some numbers for the specific implementation proposed previously, anyway. -> hack hack hack -- William Leslie _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
