Profile picture
, 3 tweets, 1 min read
My Authors
Read all threads
I wrote a synthetic program generator that can target different languages so I can get measurements across a bunch of different languages and compilers while varying the generator parameters. So far the champ among modern compilers is TCC and Delphi among historical compilers.
Even when running under a Windows 98 VM, Delphi 2 can compile large .pas files at 1.2 million lines per second. TCC comes in at 0.7 million lines per second. This is on a 2.5 GHz Skylake laptop.
All the modern Pascal compilers I could find did very poorly on the same benchmark workloads. Lazarus/FreePascal at 55 kloc/sec, Embarcadero Delphi at 15 kloc/sec.
Missing some Tweet in this thread? You can try to force a refresh.

Enjoying this thread?

Keep Current with Per Vognsen

Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

More from @pervognsen see all

Profile picture
Per Vognsen
@pervognsen
For all the (generally reasonable) advice to avoid linear-depth recursion in production code, I see little evidence that programmers at large know how to transform non-trivial recursive code into non-recursive stack-based code in a systematic way.
Aside from security/robustness concerns, it's also useful to transform push-based ("visitor") code to pull-based ("iterator") code. Even in languages with generators or coroutines, their overhead might be prohibitive.
And even though concerns about the cost of function calls are a bit old fashioned, if you have a piece of recursive code that's simple enough, you can sometimes get serious performance gains. There's an old example here: gist.github.com/pervognsen/a19…
Read 5 tweets
Profile picture
Per Vognsen
@pervognsen
Something I hadn't really considered with memory-mapped or bulk-read IO is that once you're reading through the buffer linearly interleaved with other processing, it's going to kick everything else out of the caches because of LRU replacement.
If you do traditional buffered IO where you keep updating the same buffer, that buffer's cache lines are just going to stay in cache and not pressure the rest of your working set.
E.g. consider a symbol table in a lexer/parser. Given the streaming read pattern, in theory the symbol table could use up most of your 256k L1 cache without any contention, so long as you were doing buffered IO with a buffer that's large enough to amortize each buffered read.
Read 5 tweets
Profile picture
Per Vognsen
@pervognsen
People who quote Knuth on premature optimization must not have seen his code. He's that dude who puts 'register' on variables in 2020 and implements a bespoke trie for simple one-off string processing programs.
He's so much a "premature" optimization proponent that he's still putting 'register' on variables in C after compilers stopped paying attention to them 30 years ago. It's basically him just throwing up gang signs.
2019 specimen: www-cs-faculty.stanford.edu/~knuth/program…
Read 3 tweets

Embed code for your website

×
Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!