PDoyle

8 ms·

61.
by PDoyle 10y ago
Nope. I draw your attention to this paragraph: > Zeroing the page at fault-time...
62.
by PDoyle 10y ago
Shameless self-promotion: by chance, I happened to write a blog post today that's all about information theory: "Measuring Information in Millibytes" https://engineering.vena.io/2016/07/12/measu
63.
by PDoyle 10y ago
No, not simple. Analyzing an arbitrary lisp program to determine the lifetimes of all allocated structures reduces to the halting problem, so it's undecidable. You must either restrict the input program or tolerate some leaks.
64.
by PDoyle 10y ago
Not in Canada.
65.
by PDoyle 10y ago
There are other articles like that, of course.
66.
by PDoyle 10y ago
Not true when the comments are mechanically checked for correctness.
67.
by PDoyle 10y ago
You're not the only one. It's a common sentiment if you haven't really, fully used a type system before. If there's an important property you want your program to have, and you can express it using the type system, then
68.
by PDoyle 10y ago
It doesn't. Not sure what that guy's talking about.
69.
by PDoyle 10y ago
Same happens with integers. Try computing the mean of 3 and 4 using integer math. The only difference, really, is that floating point can lull you into believing they have unlimited precision. With integer math, the problem would have bee
70.
by PDoyle 10y ago
If you're interested in memory layouts in Java, I wrote a blog post recently discussing a way to make super-tight data structures in Java: https://engineering.vena.io/2016/05/09/transpose-tree/
71.
by PDoyle 10y ago
J9 has had one-word headers for years now. I think this article was already out of date in 2012 when it was published.
72.
by PDoyle 10y ago
This article is super old. Those options are now default, and the overhead is much smaller. (I think even in 2012, we already had 1-word headers.)
73.
by PDoyle 10y ago
You're right, that's the Java/C++ way. I was trying to do it the OCaml way in Java. :-) Ultimately, what I wanted was a way to declare the variants in one place. I didn't want to repeat myself. The only way I could t
74.
OCaml mimicry in Java(engineering.vena.io)
7 points by PDoyle 10y ago|3 comments
75.
by PDoyle 10y ago
<groan> Hello World tells you nearly nothing about a programming language. (Unless, of course, it's written in Java, in which case it's a painstaking tour of the entire programming language, requiring you to learn the conce
76.
by PDoyle 10y ago
Was that the A-Team van at the start?
77.
by PDoyle 10y ago
Locality depends on many factors. True, the fields for a given object are spread out; however, they are much smaller. If you're iterating through a consecutive sequence of items in your compressed tables, you end up using the cache q
78.
by PDoyle 11y ago
Yes, that kind of "transaction-based" memory management is beautiful in applications where it's appropriate: just leak memory until you're done with the current task, and free it in one chunk. That's hard to beat f
79.
by PDoyle 11y ago
What's the point you're trying to make? That GC can't beat manual memory management on arbitrary workloads with no tuning hints? Ok then, no argument here.
80.
by PDoyle 11y ago
The difference is that free() needs to be able to free objects one-at-a-time without knowing their size, and without moving any live data around. This inevitably leads to fragmentation, one way or another.
81.
by PDoyle 11y ago
Check the title of the article. I'm comparing GC verus malloc+free specifically.
82.
by PDoyle 11y ago
I'm the author of the article, and I agree 100% with you: there are definitely application-specific memory management schemes that beat both malloc and automatic GC. In fact, I'm working on one right now: it's a way of stori