Proposal: takeFront and takeBack

[Jonathan M Davis]

On Wednesday, July 04, 2012 23:53:35 Ed McCardell wrote:
> On 07/04/2012 10:11 PM, Jonathan M Davis wrote:
> > Just adjust the strings to try different strings, and adjust then number
> > of
> > iterations if you need to. It prints out a two lines looking like:
> > 
> > ascii 82.89%:  old [5 secs, 176 ms, 602 μs, and 8 hnsecs], new [4 secs,
> > 290
> > ms, 683 μs, and 6 hnsecs]
> > uni   74.78%:  old [6 secs, 876 ms, 3 μs, and 1 hnsec], new [5 secs, 141
> > ms, 955 μs, and 6 hnsecs]
> 
> Using GDC* without optimizations, I am seeing similar numbers
> (consumeFront taking 75%-85%). With gdmd -release -O -inline (which
> translates to gdc -frelease -finline-functions -fweb -O3), I am getting
> results like this:
> 
> ascii 17.91%:  old [3 secs, 102 ms, 490 μs, and 7 hnsecs], new [555 ms
> and 747 μs]
> uni   42.80%:  old [3 secs, 929 ms, 632 μs, and 9 hnsecs], new [1 sec,
> 681 ms, 862 μs, and 7 hnsecs]
> 
> I found this surprising, since I've seen several cases of performance
> differences, between two versions of a program built with dmd, disappear
> when built with gdc (presumably, because the gcc backend is better at
> optimizing "slower" code).
> 
> --Ed
> 
> * built with gcc-4.7-20120421 snapshot and gdc at commit
> https://github.com/D-Programming-GDC/GDC/commit/a764e6947be42c0ee47f340e0ab8
> 6190401aec24

That's _way_ more of a speed increase than I've ever seen. It think that the 
best that I've seen is around 68%, never something as low as 43, let alone 18 
- and the fact that the _ASCII_ string is getting the biggest speed increase 
is even more surpising. It's pretty much always the unicode strings which get 
the biggest benefit from what I've seen (and it's what I'd expect, since the 
extra decoding necessary is worst for them). So, for it happen like that with 
an ASCII string is pretty odd.

- Jonathan M Davis