~vdupras/dusk-examples

Dusk package examples
Have examples work under ARM host
Update to Dusk v13
Pimp up sieveh.fs

refs

master
browse  log 

clone

read-only
https://git.sr.ht/~vdupras/dusk-examples
read/write
git@git.sr.ht:~vdupras/dusk-examples

You can also use your local clone with git send-email.

#Dusk Examples

This is a collection of examples of Dusk packages, that is, applications written in Dusk's Forth and wrapped through Dusk's Usermode to provide a portable executable that is small and fast.

#Requirements

Dusk's Usermode runs natively on the host machine, but this means that it can only run on CPU architectures supported by Dusk. See Usermode README for details.

To build this project, you need:

  • A C compiler
  • Make (BSD or GNU)
  • A way to fetch a file from http: either curl, wget, or BSD's ftp.

#Build

Run make in this project's root directory. This will compile all examples. These executables are standalone.

#Examples description

#hello

Invoking ./hello will print "Hello World!" and exit. Invoking it with a single argument will greet that name instead. Other arguments are ignored.

#sievec

This is a "Byte Sieve" benchmark as shown on the website's main page and compiled with Dusk CC. You run it with ./sievec without arguments. On most system, you can time it with a command that looks like time ./sievec.

This is a good example of a more complex package because it uses a filesystem to load DuskCC. It embeds a tar of Dusk's files in the executable itself and uses this as a filesystem.

It's also a good example of an API extension: access to the tar data is done through an extra API function.

On top of that, it's a good example how we can be "smart" about freezing: if you look at sievec.c, you'll see that we've carefully #ifdef-ed out the tar embedding from the frozen executable because once frozen, we don't need filesystem access anymore.

#sieve

This is a "Byte Sieve" benchmark as shown on the website's main page. You run it with ./sieve without arguments. On most system, you can time it with a command that looks like time ./sieve.

This timing will include "warm up" time, that is, the time Dusk needs to compile itself up, then compile the sieve word.

#sieveh

Same as sieve, but with the HAL-optimized version of the algorithm.

#charcount

This is a showcase of how the efficiency of the HAL isn't just about compiling C code, but how this efficiency oozes everywhere in the code, with compound effect. That makes Dusk really, really efficient.

This is a comparison of Dusk's "rfind" method, which leverages the HAL to compile a super efficient loop against POSIX's regex(3).

The idea is simple: read stdin and count the number of characters between a and d.

There is of course the Dusk version in charcount.fs, but also a reference regex(3) version in charcountref.c, which you can build with make charcountref.

Then, you can do something like time ./charcount < /usr/share/dict/words to try it out.

On my 10 years old NetBSD 10.0 machine, guess what? The Dusk version is 30 times, 30 times faster than regex(3). On a debian bookworm amd64 modern machine, the gains are more modest (Dusk is 15% faster), but it still manages to beat glibc and its millions upon millions of lines of code.