3 ms·

Cute idea. I would be worried about using vector float ops when the program only needed a scalar op, since I would expect the vector ones to be more expensive

Cute idea. I would be worried about using vector float ops when the program only needed a scalar op, since I would expect the vector ones to be more expensive somehow (either they are actually slower or they don’t get as much instruction level parallelism). Also, the scalar ops to massage the tagged float (the shift ops in the example) are hella cheap. In JSC, we have sometimes implemented optimizations to remove those only to find that it didn’t buy us anything. Finally, it’s somewhat unusual to want to tag 32-bit floats in a dynamic language setting. Usually dynamic languages have 64-bit floats.

moonchild 4y ago
On recent x86s, vector ops are generally the same speed as scalar ops, at least applied to xmm*. (Stuff like sqrt or division gets slower on bigger vectors, but that doesn't matter here.) Taking a quick look at the tables for firestorm/icestorm, it looks like the same thing applies there. > the scalar ops to massage the tagged float (the shift ops in the example) are hella cheap. In JSC, we have sometimes implemented optimizations to remove those only to find that it didn’t buy us anything Still get second-order effects from stuff like I$, or not fitting as much in your rob. Of course, for a JIT, this maybe has to be weighed against the time it takes to perform the optimisations, so I'm not surprised if it wasn't an obvious win in your case. > it’s somewhat unusual to want to tag 32-bit floats in a dynamic language setting. Usually dynamic languages have 64-bit floats. My primary interest is in common lisp, which has both single and double precision floats. Single precision is more than enough for lots of dsp-type stuff, and is half the size; better for memory b/w, and usually at least twice as fast when vectorised, too. And has the advantage that you can pass it around without immediately without making integers and pointers slow :)

moonchild 4y ago

On recent x86s, vector ops are generally the same speed as scalar ops, at least applied to xmm*. (Stuff like sqrt or division gets slower on bigger vectors, but that doesn't matter here.) Taking a quick look at the tables for firestorm/icestorm, it looks like the same thing applies there. > the scalar ops to massage the tagged float (the shift ops in the example) are hella cheap. In JSC, we have sometimes implemented optimizations to remove those only to find that it didn’t buy us anything Still get second-order effects from stuff like I$, or not fitting as much in your rob. Of course, for a JIT, this maybe has to be weighed against the time it takes to perform the optimisations, so I'm not surprised if it wasn't an obvious win in your case. > it’s somewhat unusual to want to tag 32-bit floats in a dynamic language setting. Usually dynamic languages have 64-bit floats. My primary interest is in common lisp, which has both single and double precision floats. Single precision is more than enough for lots of dsp-type stuff, and is half the size; better for memory b/w, and usually at least twice as fast when vectorised, too. And has the advantage that you can pass it around without immediately without making integers and pointers slow :)