diff options
Diffstat (limited to 'implementation')
| -rw-r--r-- | implementation/codfns.md | 2 | ||||
| -rw-r--r-- | implementation/perf.md | 2 |
2 files changed, 2 insertions, 2 deletions
diff --git a/implementation/codfns.md b/implementation/codfns.md index da1f9da0..7f6be955 100644 --- a/implementation/codfns.md +++ b/implementation/codfns.md @@ -22,7 +22,7 @@ Neither BQN nor Co-dfns significantly optimize their output at the time of writi ## Error reporting -Co-dfns initially didn't check for compilation errors, but has started to add some checks with messages. It's behind BQN, which has complete error checking and good error messages, and includes source positions in compiler errors as well as in the compiled code for use in runtime errors. Position tracking and error checking add up to a little more than 20% overhead for the compiler, both in runtime and lines of code. And improving the way errors are reported once found has no cost for working programs, because reporting code only needs to be run if there's a compiler error. The only thing that really takes advantage of this now is the reporting for bracket matching, which goes over all brackets with a stack-based (not array-oriented or parallel) method. +Co-dfns initially didn't check for compilation errors, but has started to add some checks with messages. It's behind BQN, which has complete error checking and good error messages, and includes source positions in compiler errors as well as in the compiled code for use in runtime errors. Position tracking and error checking together add about 20% to the number of lines in compiler and 10% to compile times. And improving the way errors are reported once found has no cost for working programs, because reporting code only needs to be run if there's a compiler error. The only thing that really takes advantage of this now is the reporting for bracket matching, which goes over all brackets with a stack-based (not array-oriented or parallel) method. ## Comments diff --git a/implementation/perf.md b/implementation/perf.md index 760aab6d..3fd415f8 100644 --- a/implementation/perf.md +++ b/implementation/perf.md @@ -4,7 +4,7 @@ How fast is the performance-oriented BQN implementation, [CBQN](https://github.com/dzaima/CBQN)? I must ask, why do you care? People are out there looking for the fastest array language before they've tried any one to see if it works for them. Fact is, most programs have a point where they are just fast enough, and CPUs have gotten pretty good at reaching that point. Or maybe there's a concentrated slow part that's easily handed off to a specialized tool like LAPACK. No matter what, a laser focus on performance from the beginning will cause you to miss the fast solutions you'd find if you really understood the problem. So, start with clean code in the most expressive language to work out strategy, and move to tactics once you know when and how the performance falls short. Without this understanding, benchmarks are just a dick measuring contest. It's not even your own dick. It's public, you're just using it. -Anyway, BQN's dick is pretty fast. Compiles its own compiler in 3ms. Builds this whole site—a megabyte or so of markdown—in a second and a half. Lists the primes under a billion in two seconds. That sort of thing. For CBQN right now, performance splits into three major cases: +Anyway, BQN's dick is pretty fast. Compiles its own compiler in 2ms. Builds this whole site—a megabyte or so of markdown—in a second and a half. Lists the primes under a billion in two seconds. That sort of thing. For CBQN right now, performance splits into three major cases: - Scalar code, mostly using atoms. CBQN is faster than other array languages and on par with lightweight interpreters (not JIT compilers). - Flat lists, particularly integers and characters. CBQN rarely loses to other array languages, and can beat idiomatic C. - Multidimensional arrays. CBQN has less optimization, and sometimes falls back to the self-hosted runtime which has implementations using a lot of scalar code. These can be slow, but not pathologically so. |