Snappy VS shady

Another example of Nim being really fast is the supersnappy library. This library benchmarks faster than Google’s C or C++ Snappy implementation.

It doesn't destroy performance for the simple reason that nowadays memory access has higher latency than pure compute. If you need to use compute to produce some data to be stored in memory, your overall throughput could very well be faster than without compression.

There have been a large amount of innovation on fast compression in recent years. Traditional compression tools like gzip or xz are geared towards higher compression ratio, but memory compression tends to favor speed. Check out those algorithms:

* lz4: https://lz4.github.io/lz4/

* Google's snappy: https://github.com/google/snappy

* Facebook's zstd in fast mode: http://facebook.github.io/zstd/#benchmarks

Google released Snappy, which is extremely fast and robust (both at compression and decompression), but it's definitely not nearly as good (in terms of compression ratio). Google mostly uses it for real-time compression, for example of network messages - not for long-term storage.

Just compress it! Of course if you will you ZIP, players will able to just open this zip file and change whatever they want. But you can use less popular compression algorithms which are not supported by default Windows File Explorer. Snappy for example.

I have used Nim for personal projects for 6 years now and it continues to surprise me on how well versed it is for many problem domains. I am fond of it's SPA framework, karax https://github.com/karaxnim/karax for which I wrote a translation utility https://github.com/nim-lang-cn/html2karax Latest Nimv2 release candidate has improved in the ergonomics and syntax that affect compilation to js, so I was able to cleanup my webapp's code to be less verbose. On GPU programming there has been a few projects that touch GPU programming, most notably https://github.com/treeform/shady

This includes the GPU! Yep, that’s right. You can write shaders in Nim. This makes shader code much easier to write because you can debug it on the CPU and run it on the GPU. Being able to run the shader on CPU means print statements and unit tests are totally doable.

You can do a lot with Nim at compile time, check out my talk on Nim Metaprogramming not just for FizzBuzz, but real world applications: https://fosdem.org/2022/schedule/event/nim_metaprogramming/

I am working an a macro to compile Nim code into GLSL. So not only can you write Nim to C or Nim to JS, it can also (in limited way) do Nim to GLSL GPU Shaders. See here: https://github.com/treeform/shady

I am also working on a macro system similar to SWIG, where using a some macros one can write a Nim library and generate wrappers for your NIM library for many languages like C, Python, JS, Ruby. See here: https://github.com/treeform/genny

See this as one of the examples: https://github.com/treeform/shady

It makes debugging shaders much easier as you can use print statements and unit tests. You can also share code between CPU and GPU side.