What's wrong with your HEAD?

[DavidM]

(10-08-2018 05:55 PM)3298 Wrote:  I've run some tests on real hardware, with ^ErrBadDim in all versions, and under as equal as possible conditions even in terms of garbage collection influence and memory available. I came to the conclusion that while the three variants still in discussion (mine is out, DavidM's is an obvious improvement over it) are pretty close to each other, Werner's return-stack-based variant is definitely the slowest one.

Thanks for doing that -- you saved me a lot of time!

(10-08-2018 05:55 PM)3298 Wrote:  DavidM's somehow managed to beat David Hayden's by a small margin - but consistently. No clue why, because David Hayden's reasoning about skipping appears solid to me. Maybe because SKIPOB has been migrated to ARM code?

NOTcase has one extra jump in it compared to case (presumably to use GONC instead of GOVLNG), but that should be a nit in the final timing. That's the only reason I can think of for a difference, though.

(10-08-2018 05:55 PM)3298 Wrote:  Just for fun, I tested vanilla HEAD under the same conditions. Even on the two-element list I used for testing, it was quite a bit slower than the slowest of the three. And when I tested the actual command HEAD as romptr without recalling its contents using ROMPTR@, the time went off the charts. On these small test cases a romptr apparently has a significant impact.

Which also underscores why short-and-fast library routines are much more heavily impacted by where the library is stored: the access/load time for the command code is a much greater percentage of the total execution time, so the system overhead is a more significant part of the overall performance.

(10-08-2018 05:55 PM)3298 Wrote:  Using PTR 1933C in place of ^ErrBadDim speeds up DavidM's and Werner's versions a bit more. David Hayden's version obviously doesn't benefit from that at all, because it is neither executed nor skipped there. It's also smaller and should be slightly faster in case of an error (maybe it will get caught and handled in some application?), but ultimately its down to DavidM as maintainer of ListExt to decide between that and the guarantees of a stable entry point.

As far as ListExt is concerned, I'm OK using PTR 1933C if it is stable in all ROM versions of the 49G as well as the released versions of the 49g+/50g/48gII up through 2.15. Since I don't know of a sure-fire way to verify that, I'll probably just stick with ErrBadDim.

(10-08-2018 05:55 PM)3298 Wrote:  

(10-08-2018 05:24 PM)pier4r Wrote:  Point! Then go for it!
Obviously LTAIL follows.

I don't think there's much point in trying to improve on TAIL... that would only be for symmetry.

I could see perhaps creating a symbolic link for an LTAIL command that simply maps to TAIL, just for the symmetry in naming. Although now that I'm thinking about it, how much time would be saved by not having the dispatch defined for a string object? It strikes me that I've never actually gone to the trouble to see what the incremental performance impact is for each additional defined dispatch type of a single command. More things to check!