Corollary: not 100% of the storage used by programmers and build machines should be solid state. Testing on platter drives will be important for "minimum spec" compatibility for at least 5 more years. If you always build/test from SSDs, you may become severely IO bound on older drives, and performance differences can be over 100x.
I would love to publish the actual numbers and details someday, but for now, here's a handy tip I learned the fun way from Guild Wars 2: if you use precompiled headers for C or C++, structure them carefully and monitor how much disk IO is spent reading and writing them in an average build. You may be horrified.
Seriously considering a ground-up rewrite of the #EpochLanguage compiler... Yet again. The existing project is riddled with assumptions that I don't like, is very poorly organized, and implements a language that is almost - but not quite - what I want it to be.
If I do it, I will keep large chunks of the existing code (linker mostly). But it's a big enough lift that I am very hesitant.
Anyone got some recommendations for reducing .PCH file sizes? Besides the obvious one ("include less").
I would love to have Clang's chained PCH support in Visual Studio, but oh well.
Presently doing 50GB of disk IO just on PCHs for every clean build of a certain project. Would love to make that number a lot smaller.
Computers are truly amazing. I can transfer literally billions of pieces of information from one place to another in a second.
Software is equally amazing. I can squander the immense performance capabilities of the computer effortlessly by writing some sloppy code.
Turns out cache invalidation is still a Hard Problem.
Renewing my search for users (or instances!) that might have an interest in #ProgrammingLanguages - particularly design and implementation.
Here is my current project: https://github.com/apoch/epoch-language
(It isn't very approachable right now, but I am making good progress on the second self-hosted compiler and IDE integration with VS2017.)
The quintessential Friday afternoon is listening to a discussion about design patterns get drowned out by random people saying "blood!" in silly voices.
On side projects, I tend to prefer committing code in many tiny changes. The only time I (generally) commit more than a function or two is when the pieces are inseparably coupled.
This is mostly only practical on solo projects. At work I make much larger commits but routinely shelve code while working on them, as a sort of serialized Undo/Redo stack.
I would really like to understand why LLVM's CodeView support generates symbol types that are rarely (never?) emitted by actual Microsoft compilers.
Getting the Visual Studio debugger to properly inspect variables has been a long running nightmare, punctuated by "temporary" hacks and workarounds.
It really reinforces my strong suspicions that LLVM is philosophically hostile to debuggers (see: inspecting its source code in a debugger is a waste of time).
Recently resumed work on #EpochLanguage after a couple months off. Currently striving for a 64-bit self hosted compiler.
The 64-bit self host is so far smoother than 32-bit was, largely because the debugging experience is much better. Having PDB symbols is a huge win, even without variable inspection.
Low key pet peeve: saying C is "close to the metal."
It is *closer* than virtually any other structured language in use today, but C is still fundamentally a considerable abstraction layer over hardware.
Even when it was first gaining traction, C was appealing *because* it was in fact reasonably far removed from "the metal."
I feel conflicted about movie villains that meticulously plan their lives.
We're supposed to dislike them, but they're just so organized and methodical and rigorous... How do you dislike that?
Oh... Most people don't place life value on having a thousand contingency plans for every inconceivable scenario, do they.
Project Technical Director, Guild Wars 2 (ArenaNet). Interested in programming languages, game AI, and making life better.
Game development! Discussions about game development and related fields, and/or by game developers and related professions.