Thanks, Ben. I admit I mostly think tracing is just a mind-expanding concept to learn about, even if history has proven it’s not very practical as an organizing principle. But as you say, I’d love to offer more context on “what actually seems to work” industrially.
I had an identical experience with the REALbasic Cafe as a kid, down to eventually selling a couple of shareware projects. I wonder if we were there at the same time.
I think it would be more like RPN if it used a stack, and operands were specified as relative offsets (i.e., stack offsets). In the version I wrote, operands are still represented as absolute offsets in the expression table.
Hi! This course is about the "middle end," FWIW. We do not do parsing or codegen in 6120, and there is no goal (as there is in many undergrad-level compilers courses) of making a complete, end-to-end compiler for a C-like language.
To slightly refine this, Intel didn't have many "foundry customers" before Altera. Via Wikipedia (https://en.wikipedia.org/wiki/Intel#Opening_up_the_foundries...), the need to fill up the manufacturing lines was engendered by poor x86 CPU sales around ~2013, not poor third-party fab runs. In 2013, Intel was still ahead of TSMC with 22 nm.
> The diagram shows each core has icache and dcache; what they've ditched is cache coherency.
This is not quite true: the local data memories are not caches, i.e., they do not implicitly move memory in from a more distant tier in the memory hierarchy. They are just plain explicitly managed local memories (sometimes called "scratchpads" to distinguish them from caches).
> However, where it starts to get more interesting is the work done by W. Bastiaan Kleijn from Cornell University Library.
The authors are not from Cornell. I think the author made this mistake because the paper is posted on arXiv, and that’s what’s it says at the top of every page?
Mine's called Hooknook. It takes care of updating the GitHub repository for you on push and then invokes a command inside the repository. https://github.com/sampsyo/hooknook
As it stands, I'd agree with that---but the characterization definitely depends on who you talk to. I might be in the minority among "PP people," since the hype is still going strong and some smart people seem to see more potential than I (and you) do.
(I'm the author of the lecture notes.) I totally agree, and this is an underappreciated view in the PP community. The hype says "you just write your model; you'll get inference for free," but that obscures that current languages do nothing to help with cooking up an efficient inference algorithm for a particular situation. That's still a hard problem. When the only inference algorithm anyone actually uses is some MCMC variant, I think that's a broken promise.
There's some chance we'll be able to find clever new ways to derive better inference algorithms in specific situations using program analysis, but I wouldn't hold my breath. And it's impossible, of course, for anything like that to work for every possible program in a Turing-complete language.
Needless to say, I disagree. It can be straight-up misleading to report means without including a more nuanced view of the distribution. You don't need to use a bunch of fancy statistics, but you do need to consider whether your results could have arisen by random chance. That's not a distraction; it's accurately reporting what you found.
But we also have to remember that, to someone not in those well-represented groups, it's not a huge consolation. Diversity isn't a floating-point number between 0.0 and 1.0.