sb-simd VS prechelt-phone-number-encoding

> fully dynamic

Well, no, it's SBCL. Common Lisp has support for types, but most compilers only use them for optimization, SBCL goes one step further and emits warnings when you mismatch types. And looking at the code, I can see lots of type declarations.

It's also interesting to note that the code does not seem to be using SBCL's new SIMD library*, so it could be sped up even more.

* <https://github.com/marcoheisig/sb-simd>, see the texinfo file for documentation.

I suppose that using arrays + using SIMD instructions could be even faster. Someone is already doing that: https://github.com/marcoheisig/sb-simd/blob/master/examples/simd-dot.lisp .

Common Lisp (sbcl) performance via native implementation of simd [0] is very impressive ! It is litteraly acheieving C/Cpp speeds (within few ms). Great work by Marco Heisig

[0] https://github.com/marcoheisig/sb-simd

Here is another demonstration of how effective SIMD vectorization can be using sb-simd.

You can see on Programming Language and Compiler Benchmark site the amazing speed of SBCL when sb-simd is used for vectorization.

For SBCL-specific, Marco and Bela have put in a ton of work at sb-simd - may be the OP finds the relevant simd interface there!

And sb-simd is getting very-very impressive to say the least thanks to Marco Heisig.

You can use sb-simd for manual vectorisation with SBCL. Manual vectorisation is definitely more hassle than automatic vectorisation, but often worth it.

Fully agreed. One more library that could open up areas is also coming soon. Though documentation is still to be written. Please check sb-simd I wish I could have supported Marco even more.

You're looking at the non-optimized version. If you read the blog post you would've seen your suggestions had already been implemented.

> it’s using Unicode-aware string stuff

Rust uses UTF-8 internally for Strings, so it's very efficient to parse a file into a String, then using slices to go through it... this is probably the best you can get as parsing ASCII input as UTF-8 is very efficient (the 0-bit is always zero in ASCII, the unicode decoder only needs to check that's the case for every byte, so it's not some kind of complicated computation it's doing to decode)...

If you use bytes for everything, you will make the whole code much harder to follow and it still won't run faster.

Check for yourself: https://github.com/renatoathaydes/prechelt-phone-number-enco...

This is a pretty introductory CL article, mostly a commentary on Norvig's solution to the problem. Still, I learned about the #. readmacro from it. The conclusion: "[The Lisp implementation] was the fastest implementation for all input sizes except the largest one, where it performed just slightly worse than my best Java implementation." GH repo at https://github.com/renatoathaydes/prechelt-phone-number-enco.... Sounds like he was mostly measuring the performance of the SBCL bignum implementation.

Here are the commits I've made so far. If anyone wants to help write the most efficient possible Lisp implementation, please send suggestions here!

OMG you're right... I'm the author, and the reason it was allocating in my original code was that I was calling the operators on a reference to n. See https://github.com/renatoathaydes/prechelt-phone-number-encoding/commit/6683dc10cc4fb380abead632b87d94e8937f8377

This commit show how to improve that: https://github.com/renatoathaydes/prechelt-phone-number-encoding/commit/561a7307b5574bd6fd7b8cc638abf6f29884b6ca

See https://github.com/renatoathaydes/prechelt-phone-number-encoding/issues/6

I get the need to want to obsessively optimize the code. There's nothing more fun than to optimize something simple, artificial, and narrowly-defined. But y'all need to take a deep breath, step back, and realize that one blog post isn't going to suddenly define the language (nor should it personally define you).

source: https://github.com/renatoathaydes/prechelt-phone-number-enco...