In this (very primitive!) benchmark, MKL was a bit better than eigen (~10%) on my machine (i5-6600).
Since the article https://justine.lol/matmul/ compared the new kernels with MLK, we can (by transitivity) compare the new kernels with Eigen this way, at least very roughly for this one use-case.
Thanks for the feedback! My code snippets in the article don't use any real/existing language. C# for example, is quite explicit with the transformation of generated to state machines, but also does not provide such methods, as far as I know. I've just added a comment explaining this choice: https://github.com/Dobiasd/articles/commit/f44b897f2a4d20aa9...
The interview for my current job first went mediocre, but by talking about frugally-deep (a side project of mine) I was able to excite my (now) employer. :-)
> I spent some time over those 30 years looking at new IDEs, trying them out, configuring them, and each and every time this was time wasted, because the IDE was discontinued, abandoned, or otherwise became useless.
"wasted" sounds a bit too hard to me. If you learn and use some tool productively for some years, even if this stops, the years were not wasted. Ephemeral things can also have value.
Yeah, this one does something much less insane, i.e., it converts the paths to the tree outputs into their corresponding DNS (disjunctive normal form) and represents each term as a node (side by side in the same layer) in the NN, as described by Arunava Banerjee in "Initializing Neural Networks using Decision" [1]. The resulting NN architecture is much more reasonable than the one that treebomination produces.
Thanks! This looks interesting. Some of the main differences I can spot so far are:
- Hummingbird does not construct a NN with an architecture isomorphic to the source decision tree but instead cleverly compiled it into other (more sane) tensor computations.
- Hummingbird is actually useful. ;)
It's a website for practicing manipulating text (start -> target, like a diff) quickly (timed) and efficiently (few keystrokes). The allowed keyboard shortcuts are only the "common" ones, that you can use in most "normal" (not Vim, not Emacs) text editors or IDEs.
I made this page not only because I was interested in building it, but also because I actually wanted to have such a training tool. Turned out, I really like using it, but almost nobody else does. :D (There are ads, but the revenue is basically zero.)
> 1. It allows for minimal disruption to thinking process, close to 90% of the time even when coding is not actively typing, but when typing is subconscious and fast it removes the potential of where it interrupts the thinking process.
I agree, and even wrote an article about that a few years ago. :-)
The mouse is located on the armrest (I don't need to use it too often), and the keyboard (a heavy and thus stable one) is on my lap (I don't need to look at it while typing).
> This article feels like it was written by someone half-way through [...]
You might be right. I'm not a principal engineer. :)
The first solution in the wild we came up with back then when confronted with this problem, actually was to use a lock-free queue. Only later we figured out, that we did not need the prioritizing after all, and our software worked just fine with all threads having the default priority.
> I would like to understand why priority inversion is not a solved problem.
Maybe I just was not careful enough in choosing this phrasing when writing the article.
Do you think it would make sense if I change "but it's far from being solved once and for all." to "each of them with different upsides and downsides."?
In this (very primitive!) benchmark, MKL was a bit better than eigen (~10%) on my machine (i5-6600).
Since the article https://justine.lol/matmul/ compared the new kernels with MLK, we can (by transitivity) compare the new kernels with Eigen this way, at least very roughly for this one use-case.