diff options
Diffstat (limited to 'docs/implementation/perf.html')
| -rw-r--r-- | docs/implementation/perf.html | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/docs/implementation/perf.html b/docs/implementation/perf.html index 7e9dc1ff..c12b68e5 100644 --- a/docs/implementation/perf.html +++ b/docs/implementation/perf.html @@ -6,7 +6,7 @@ <div class="nav">(<a href="https://github.com/mlochbaum/BQN">github</a>) / <a href="../index.html">BQN</a> / <a href="index.html">implementation</a></div> <h1 id="how-does-bqn-perform"><a class="header" href="#how-does-bqn-perform">How does BQN perform?</a></h1> <p>How fast is the performance-oriented BQN implementation, <a href="https://github.com/dzaima/CBQN">CBQN</a>? 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.</p> -<p>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:</p> +<p>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:</p> <ul> <li>Scalar code, mostly using atoms. CBQN is faster than other array languages and on par with lightweight interpreters (not JIT compilers).</li> <li>Flat lists, particularly integers and characters. CBQN rarely loses to other array languages, and can beat idiomatic C.</li> |