4 ms·

Good performance improvement here: https://world-playground-deceit.net/blog/2025/03/speeding-up-cljqalbum.html https://world-playground-deceit.net/blog/2025/03/

by pama 1y ago

Good performance improvement here: https://world-playground-deceit.net/blog/2025/03/speeding-up-cljqalbum.html https://world-playground-deceit.net/blog/2025/03/speeding-up...

stassats 1y ago
>(safety 0) Please, don't do that!
- sauercrowd 1y ago
  Why's that? What does it do?
  - aidenn0 1y ago
    The Lisp standard allows it to be implementation dependent, but in SBCL (which I believe the author of TFA is using), it disables all runtime type and bounds checking. This usually speeds things up negligibly[1] in exchange for allowing all kinds of undefined behavior. 1: If it speeds things up non-negligibly, there's almost always a way to get a similar speedup without setting safety to 0; e.g. if you check your types outside of your hot loops, the compiler is smart enough to omit type-checks inside the loop.
    - jlarocco 1y ago
      Honestly it's more nuanced than that, and probably not such a big deal. It's kind of like building in Debug mode in other languages. Internally and for testing, use (safety 3). If the code in question doesn't trigger any errors or warnings, then in most cases it's safe to turn (safety 0) and get the tiny performance boost. I wouldn't recommend (safety 0) globally, but it's probably fine locally in performance critical code that's been tested well, but I do agree it's probably not worth going to (safety 0) in most cases. The best solution is a compiler who's (speed 3) optimization level is smart enough to optimize out the unnecessary safety checks from (safety 3). I think SBCL can do that in some cases (the safety checks get optimized for speed, at least).
      - aidenn0 1y ago
        > If the code in question doesn't trigger any errors or warnings, then in most cases it's safe to turn (safety 0) and get the tiny performance boost. This is trivially not true. Consider: (defun foo (x) (declare (safety 0) (type x (array fixnum (4))) [Lots of code that doesn't trigger any warnings]) Then in a different source file doing e.g: (foo nil) Nothing good will come of that. > I wouldn't recommend (safety 0) globally, but it's probably fine locally in performance critical code that's been tested well, but I do agree it's probably not worth going to (safety 0) in most cases. > The best solution is a compiler who's (speed 3) optimization level is smart enough to optimize out the unnecessary safety checks from (safety 3). I think SBCL can do that in some cases (the safety checks get optimized for speed, at least). The only thing I can think of is that I communicated things poorly in my comment, because this is nearly exactly what I was saying in my comment.
        jlarocco 1y ago
        Sure, that code fails with a memory fault with (safety 0). But I explicitly recommended testing and debugging with (safety 3) first, and in that case it gets a type-error and doesn't crash. Once the broken `(foo nil)` is fixed and it's time to ship a release build to the user, it should be safe to drop down to (safety 0). I think we both agree that 99.9% of the time it's not worth using (safety 0), though.
- BoingBoomTschak 1y ago
  True, this was initially for the sake of benchmarking. Very bad idea, especially since it doesn't really benefit here.
naniwaduni 1y ago
This is a bit of a nonsense benchmark—the author is basically benchmarking process startup time, and finding that if you only start one lisp process, it runs faster than if you start one jq process per input file, which runs faster than if you start one lisp process per input file. This becomes quite clear at the end when they compare multiple jq implementation (which are known to have nontrivially different parsing performance characteristics, which is the bulk of the "real work" for this task lies) and come up with execution times on the same order of magnitude. A more apples-to-apples comparison would be to use find {} + to pass multiple filenames to jq and output using input_filename.

by pama 1y ago

Good performance improvement here: https://world-playground-deceit.net/blog/2025/03/speeding-up-cljqalbum.html https://world-playground-deceit.net/blog/2025/03/speeding-up...

stassats 1y ago

>(safety 0) Please, don't do that!

sauercrowd 1y ago
Why's that? What does it do?
- aidenn0 1y ago
  The Lisp standard allows it to be implementation dependent, but in SBCL (which I believe the author of TFA is using), it disables all runtime type and bounds checking. This usually speeds things up negligibly[1] in exchange for allowing all kinds of undefined behavior. 1: If it speeds things up non-negligibly, there's almost always a way to get a similar speedup without setting safety to 0; e.g. if you check your types outside of your hot loops, the compiler is smart enough to omit type-checks inside the loop.
  - jlarocco 1y ago
    Honestly it's more nuanced than that, and probably not such a big deal. It's kind of like building in Debug mode in other languages. Internally and for testing, use (safety 3). If the code in question doesn't trigger any errors or warnings, then in most cases it's safe to turn (safety 0) and get the tiny performance boost. I wouldn't recommend (safety 0) globally, but it's probably fine locally in performance critical code that's been tested well, but I do agree it's probably not worth going to (safety 0) in most cases. The best solution is a compiler who's (speed 3) optimization level is smart enough to optimize out the unnecessary safety checks from (safety 3). I think SBCL can do that in some cases (the safety checks get optimized for speed, at least).
    - aidenn0 1y ago
      > If the code in question doesn't trigger any errors or warnings, then in most cases it's safe to turn (safety 0) and get the tiny performance boost. This is trivially not true. Consider: (defun foo (x) (declare (safety 0) (type x (array fixnum (4))) [Lots of code that doesn't trigger any warnings]) Then in a different source file doing e.g: (foo nil) Nothing good will come of that. > I wouldn't recommend (safety 0) globally, but it's probably fine locally in performance critical code that's been tested well, but I do agree it's probably not worth going to (safety 0) in most cases. > The best solution is a compiler who's (speed 3) optimization level is smart enough to optimize out the unnecessary safety checks from (safety 3). I think SBCL can do that in some cases (the safety checks get optimized for speed, at least). The only thing I can think of is that I communicated things poorly in my comment, because this is nearly exactly what I was saying in my comment.
      - jlarocco 1y ago
        Sure, that code fails with a memory fault with (safety 0). But I explicitly recommended testing and debugging with (safety 3) first, and in that case it gets a type-error and doesn't crash. Once the broken `(foo nil)` is fixed and it's time to ship a release build to the user, it should be safe to drop down to (safety 0). I think we both agree that 99.9% of the time it's not worth using (safety 0), though.
BoingBoomTschak 1y ago
True, this was initially for the sake of benchmarking. Very bad idea, especially since it doesn't really benefit here.

naniwaduni 1y ago

This is a bit of a nonsense benchmark—the author is basically benchmarking process startup time, and finding that if you only start one lisp process, it runs faster than if you start one jq process per input file, which runs faster than if you start one lisp process per input file. This becomes quite clear at the end when they compare multiple jq implementation (which are known to have nontrivially different parsing performance characteristics, which is the bulk of the "real work" for this task lies) and come up with execution times on the same order of magnitude. A more apples-to-apples comparison would be to use find {} + to pass multiple filenames to jq and output using input_filename.