Re: Drawing the line between speed and simplicity/elegance

On Wed, May 6, 2015 at 9:25 PM, Javier Guerra Giraldez <javier@guerrag.com> wrote:

Roberto's position was "Lua and LuaJIT are different languages, pick
one". a corollary is that optimizing for one is different from
optimizing for the other.

Just "picking one" kinda feels like a cop-out, on my part. But I do take to heart your point about optimizing for one versus the other is different; it's what I'm seeing here. I'd rather not two different stacks, depending on the host interpreter, but I've got an idea for a third option that I'm hopeful will be nice and zippy on both.

Hisham's position was "you can write very compatible code that will
run nicely on Lua 5.1, 5.2, 5.3, LuaJIT 1.0, 2.0, 2.1. aim for
readability/maintainability, it will be fast enough for almost any
need"

I agree with this in general, but the stack is both the central data structure *and* logic flow mechanism in my language (inspired by forth). So it will be the basis for many layers of client code on top of it. Imagine Roberto et al writing a new, simpler implementation of Lua tables for an update; they profile it and it's actually even faster under GCC, but a couple orders of magnitude slower than the original, under Clang. The internet would revolt.

It was thus said that the Great Sean Conner spake:

As long as you can avoid nil, then table.insert() and table.remove()
implement a LIFO stack (since both default to the last position). That is:

push = table.insert
pop = table.remove

How much more compilicated is your ADT?

This is actually exactly what I was doing, originally. But I have to check for underflow for most operations. And nil is a valid value. And using insert/remove causes some extra GC thrash. And even if you're just poking at the end position, insert and remove take linear time because the use the # operator (or equivalent function?) which counts the entire array from 1 every time, so I have to cache and update the stack height. And, and, and...

Brigham Toskin