4 ms·
Yeah and while we're at it, we can rewrite the whole thing on top of the JVM-- get some killer constant folds goin' on. Servers usually have super long uptimes
by nickysielicki 11y ago
Yeah and while we're at it, we can rewrite the whole thing on top of the JVM-- get some killer constant folds goin' on.
Servers usually have super long uptimes, too. So the only valid criticism of JIT, which is warm up, will be a nonfactor!
(big /s if not obvious.
JIT and ML evangelists make me sick.)
- wutf 11y agoI love how I got super downvoted for an idea that is quite possibly central to the future of computing. It's as if HackerNews never realized that they themselves are machine-learning-based scheduling algorithms. Guess that one is going to hit them pretty hard.
- lgunsch 11y agoI wouldn't be so hard on JIT. JIT algorithms can massively speed up solutions to particular problems. For example, grep uses libpcre, which is one of the fastest regex engines around, and it uses JIT compilation.
- burntsushi 11y agoThis is kind of misleading. grep has an option to enable PCRE matching (the -P flag), but it by default still uses a combination of Boyer-Moore, Commentz-Walter (like Aho-Corasick) and a lazy DFA. Also, Rust's regex engine (which is based on a lazy DFA) is giving PCRE2's JIT a run for its money. ;-) https://gist.github.com/anonymous/14683c01993e91689f7206a18675901b#file-pcre2-rust https://gist.github.com/anonymous/14683c01993e91689f7206a186...
- lgunsch 11y agoAh, okay. I didn't realize that. I was trying to point out there are everyday valid use cases for JIT that don't involve the JVM. I've used Rust's regex engine before, it's very promising. It's really neat how the regex itself is fully compiled.
- burntsushi 11y agoYeah, you're absolutely right to point out PCRE2's JIT. It is indeed quite fast---I'm not entirely convinced a DFA approach can beat it in every case!