From 8389e763344637c01d0d7161091e5f2cd9b14251 Mon Sep 17 00:00:00 2001 From: Marshall Lochbaum Date: Mon, 27 Jun 2022 22:00:55 -0400 Subject: Yet still more editing --- implementation/compile/dynamic.md | 2 +- implementation/kclaims.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'implementation') diff --git a/implementation/compile/dynamic.md b/implementation/compile/dynamic.md index 2cf4979f..311fb90e 100644 --- a/implementation/compile/dynamic.md +++ b/implementation/compile/dynamic.md @@ -83,7 +83,7 @@ If the implementation is able to make use of all available threads (possible whe ### Anticipation -The [hot path](#hot-paths) strategy depends on targetting code for optimization based on history. Anticipation would identify in advance what code will take longer to run, and allocate a fraction of the time taken for optimizing that code. This is most useful for code that runs a small number of times on large arrays. An example where anticipation would be very important is for a programmer trying experimental one-off queries on a large dataset. +The [hot path](#hot-paths) strategy depends on targeting code for optimization based on history. Anticipation would identify in advance what code will take longer to run, and allocate a fraction of the time taken for optimizing that code. This is most useful for code that runs a small number of times on large arrays. An example where anticipation would be very important is for a programmer trying experimental one-off queries on a large dataset. The end result seems similar to that obtained by thunks as discussed at Dyalog '18 ([video](https://dyalog.tv/Dyalog18/?v=-6no6N3i9Tg), [slides](https://www.dyalog.com/user-meetings/uploads/conference/dyalog18/presentations/D15_The_Interpretive_Advantage.zip)). A thunk runs as part of a primitive, detecting that computing the result will be slow and outputting a deferred computation instead. Anticipation is more powerful because it can scan ahead in the bytecode instead of deciding as primitives are called whether or not to expand the thunk. diff --git a/implementation/kclaims.md b/implementation/kclaims.md index 9b7d7ecd..3781aa7d 100644 --- a/implementation/kclaims.md +++ b/implementation/kclaims.md @@ -36,7 +36,7 @@ K's design is well-suited to interpreting scalar code because of its simplicity. But K still isn't good at scalar code! It's an interpreter (if a good one) for a dynamically-typed language, and will be slower than compiled languages like C and Go, or JIT-compiled ones like Javascript and Java. A compiler generates code to do what you want, while an interpreter (including a bytecode VM) is code that reads data (the program) to do what you want. Once the code is compiled, the interpreter has an extra step and *has* to be slower. -This is why BQN uses compiler-based strategies to speed up execution, first compiling to [object code](vm.md#bytecode) and then usually further processing it (compilation is fast enough that it's perfectly fine to compile code every time it's run). In particular, CBQN can compile to x86 to get rid of dispatching overhead. And ktye's somewhat obscure K implementation now has [an ahead-of-time compiler](https://github.com/ktye/i/tree/master/kom) targetting C, which is great news. Commercial K and Q are always described by developers as interpreters, not compilers, and if they do anything like this then they have kept very quiet about it. +This is why BQN uses compiler-based strategies to speed up execution, first compiling to [object code](vm.md#bytecode) and then usually further processing it (compilation is fast enough that it's perfectly fine to compile code every time it's run). In particular, CBQN can compile to x86 to get rid of dispatching overhead. And ktye's somewhat obscure K implementation now has [an ahead-of-time compiler](https://github.com/ktye/i/tree/master/kom) targeting C, which is great news. Commercial K and Q are always described by developers as interpreters, not compilers, and if they do anything like this then they have kept very quiet about it. ## Parallel execution -- cgit v1.2.3