Yann Collet

Here are some software engineering blogs from my RSS reader in addition to the ones listed in TFA. I honestly don't know how over or underrated they are, but I guess that varies depending on which communities you're closer to.

Mikola Lysenko https://0fps.net

Graphics programming, geometry and algorithms.

---

Steven Wittens http://acko.net

Not underrated in any sense of the word, but I have to include it in case there are people who haven't seen it yet. It's about math and graphics, but also about art and design. Amazingly educational.
http://acko.net/blog/how-to-fold-a-julia-fractal/ is a good starting point for new readers.

---

Mark Nottingham https://www.mnot.net/blog/

Networking and HTTP.

---

Jeff Preshing http://preshing.com

Efficient concurrent data structures.

---

Bruce Dawson https://randomascii.wordpress.com

Software efficiency, performance optimization, fractals and more.

---

Yann Collet http://fastcompression.blogspot.com

Modern compression algorithms.

---

Gil Tene http://stuff-gil-says.blogspot.com

Also definitely not underrated, at least not in the Java world. But any engineer who cares about latency and honest benchmarks will benefit. Low latency techniques, GC performance, lock-free programming.

---

Tony Finch http://fanf.livejournal.com

C and UNIX programming, and more.

---

Andy Wingo https://wingolog.org

Scheme, Compilers, JavaScript, and much more.

---

Aleksey Shipilёv http://shipilev.net

JDK internals, low-level optimization.

Here are a bunch of blogs from my RSS reader that I think are worth reading. Some of them haven't updated in a while, but the archives may be worth a look anyway.

* Blogs with a math focus:

http://blog.sigfpe.com

http://bit-player.org

http://mathr.co.uk/blog/

https://www.johndcook.com/blog/

* Blogs with a programming languages focus:

https://existentialtype.wordpress.com

https://bluishcoder.co.nz

http://blog.ezyang.com

http://akkartik.name

http://lambda-the-ultimate.org

http://mrale.ph

* Blogs with a UI design focus:

http://www.brandonwalkin.com/blog/

http://ignorethecode.net/blog/

http://interuserface.net

* Blogs with a graphics / 3D rendering focus:

http://c0de517e.blogspot.com

http://diaryofagraphicsprogrammer.blogspot.com

https://directtovideo.wordpress.com

http://graphicrants.blogspot.com

http://www.reedbeta.com

http://www.realtimerendering.com/blog/

https://blog.demofox.org

http://eelpi.gotdns.org/blog.wiki.html

* Other interesting / more general programming blogs (many of these have a "systems" focus):

http://danluu.com

http://ewontfix.com

http://chneukirchen.org/blog/

http://neverworkintheory.org

http://apenwarr.ca/log/

https://www.snellman.net/blog/

https://www.pvk.ca

http://psy-lob-saw.blogspot.com

https://randomascii.wordpress.com

http://fastcompression.blogspot.com

https://fgiesen.wordpress.com

http://blog.plover.com

http://chneukirchen.org/trivium/

http://rachelbythebay.com/w/

This looks very interesting. Before everybody starts making the obvious comparisons, note that this is from the same guy that made LZ4, and he is someone who clearly knows what he's doing. I've been following his work for some time.

It looks like this is the evolution of Zhuff, an experimental (closed-source) compressor [1]. It is basically LZ4 followed by a fast entropy coder, specifically FSE [2], that is a flavor of arithmetic coding that is particularly suited for lookup-table based implementations.

From a quick look at the source code it seems that the entropy stage uses 3 probability tables, one for literal bytes, one for match offsets, and one for match lengths. This is not dissimilar from gzip (which however uses Huffman).

EDIT: from a second look it seems that the LZ77 compression stage is basically LZ4: it uses a simple hash table with no collision resolution, which offers very high compression speed but poor match search. I'm surprised he didn't implement (yet?) an HC variant as for LZ4, it could even beat gzip compression rate with no overhead in decompression speed/memory requirements.

[1] http://fastcompression.blogspot.fr/p/zhuff.html

[2] https://github.com/Cyan4973/FiniteStateEntropy

Nice writeup! FSE, one of the parts of Zstandard, is a very elegant entropy coder. If you're following this section of the article, you might be wondering how it's encoded, since the encoding process is somewhat less obvious than for Huffman coding.

What causes trouble is simply, "Once you've emitted a symbol, how do you know that the next symbol is in the range [BL, BL+2^NB)?" The answer is that the encoding is performed backwards, starting from the end of the input, and the table is constructed so that for any symbol emitted, you can find a previous symbol so that the current symbol is in the previous symbol's [BL, BL+2^NB) range.

There's another writeup about FSE here, which goes into more depth about FSE (rather than talking about Zstandard in general):

http://fastcompression.blogspot.com/2013/12/finite-state-entropy-new-breed-of.html

My intuition tells me that there's probably a homomorphism from Huffman coding to FSE that preserves the encoded size exactly, but I haven't done the math to check.

Very nice introduction.

Recently I've been following the progress of the Finite State Entropy algorithm[1]. From the readme on the github project [2]:

>FSE is a new kind of Entropy encoder, based on ANS theory, from Jarek Duda.

>It is designed to compete with Huffman encoder and Arithmetic ones.

>While huffman is fast but can only represent probabilities in power of 2 (50%, 25%, etc.) arithmetic coding can represent probabilities with much better accuracy, but requires multiplications and divisions.

> FSE solve this dilemma by providing precise probabilities, like arithmetic does, but using only additions, masks and shifts.

> This makes FSE faster, on par with Huffman speed, and even suitable for low-power CPU environment.

[1]: http://fastcompression.blogspot.com/2013/12/finite-state-entropy-new-breed-of.html
[2]: https://github.com/Cyan4973/FiniteStateEntropy

Discussed a couple years ago here: https://news.ycombinator.com/item?id=5037089

And the followup discussed here:
https://news.ycombinator.com/item?id=5075370

I repost because I'm becoming more and more frustrated with C, and wondered if others feel the same. Not because it's too low-level, rather because it seems to be trying (with limited success) to move to being a higher level language. There are times when I really do want a "thin layer over assembly", and C seems to have evolved to a place where that is no longer possible. I explain my distress more completely in the comments of Yann's article here: http://fastcompression.blogspot.com/2014/11/portability-woes-endianess-and.html