I started using emacs about seven years ago after about eight years of exclusively using vim, primarily because I wanted to see what the editor war's were all about (and because I got the blues from work and needed something uplifting...) I agree with the learning curve, and constantly am fine tuning my setup and configuration, but once you've mastered the basics, it truly becomes one of the most powerful editors. Plus it is constantly evolving (e.g., multiple cursors).
Another good emacs guide that I came across recently is:
In general many commenters have a misconception that the mentioned French "baccalaureate" is related to the US/UK undergraduate bachelor's degree. As the article points out, and the corresponding wikipedia page hints at, this somewhat roughly translates to a high school diploma in the US, the British A-levels, the German Abitur, etc.
There is an interesting comment that illustrates the distinction between US/Europe education systems by observing that in Europe high schools are general followed by focused specific subject studies, whereas in the US there is a lot of focusing already happening in the high schools. Interestingly, though, there seems to be a general education requirement for an undergraduate degree; since I am from Europe this seems to have the purpose of ensuring that all admitted students get to the same level before specializing.
Managing free memory is indeed an interesting problem. Besides the simple free-list approach sketched by the author (sidestepping the first-fit vs. best-fit search strategy, which affects fragmentation, too), I always found the buddy-list to be particularly interesting:
In the allocator I wrote (see the Stremflow heading: http://www.scott-a-s.com/projects/), I used both a free-list and the buddy algorithm.
The free-list was for small object allocations; it maintained free-lists of different sizes. (Say, the 8 byte free list, the 16 byte free list, the 32 byte free list, etc.) However, I obtained the memory for these lists from a page manager, and that page manager used the buddy system. The relationship here is that the small-object part of the allocation obtained its memory from the page allocator; the page allocator obtained its memory from the operating system. This system allowed me to have the benefits of a free-list (good cache behavior for small objects allocated and used together), but low overall fragmentation and good reuse of the free lists.
Full details are in our paper: http://www.scott-a-s.com/files/ismm06.pdf I have portions of a draft of a more detailed explanation that I never got around to finishing and publishing.
A couple of years ago, I read his paper "Definitional Interpreters for Higher Order Languages" [1], because it was suggested to me by a friend. It was a joyful read, and to the best of my knowledge it is the first treatment of how to implement higher-order language constructs in a first-order language. Just recently, I thought of the paper, so it's sad news that the author has died...
I tried Oberon once and have to say that it was way ahead of its time. Not only did the author (of the linked paper) invent one of the first JIT compiled systems, but also the ability to execute code with a mouse click (similar to Rob Pike's ACME editor) is---for a systems programming language---still not available today.
There were several novel research ideas tried for the Oberon system. I remember there was some paper called "Active Text" that allowed putting videos into code comments. (Probably that could have been done in Smalltalk, too.)
Finally, all of the books explaining details are heartily recommended. Wirth's compiler book (referred to at HN several times) is a classic easy-going introduction (the Oberon-0 grammar fits on only two pages IIRC! [1]), his algorithm book (also available for download, also referred to multiple times at HN) has some of the nicest descriptions that I did not find anywhere else (showing a divide-and-conquer approach to computing the median [near the Quicksort treatment]; plus polyphase sort, which might be useful again in data centers), and finally the Project Oberon book contains some unique treatment on system software that is not easily found anywhere else. For example, it contains the details on what's called PieceLinkText, which is the (at least AFAIK) best data structure to implement a text editor and it's operations. (Predating rope-strings by a fair amount of time, too.)
edit:
[1]: just checked my own copy; Oberon-0's grammar actually fits on one page, the full Oberon grammar fits on two pages!
ad 1: Please also do keep in mind that there are career steps after obtaining tenure. If you say "Fuck it" right after getting tenure, you are almost certain to never make it thus far.
I also do agree with the other comment regarding funding agencies. Another problematic way that NSF does business (inviting professors for peer review that is) is that this virtually guarantees that some of your peers know exactly what you're doing, which reduces effectiveness of double-blind submissions substantially (to the point where it is hard to believe it works at all; didn't it ever occur strange to anyone that the same people from the same top schools are consistently successful? [with grants and publications in the top venues])
On the first part, that's true, but you don't have to actually care about those further career steps. Tenure you have to care about, because you're out of a job if you don't get it. But a tenured professor in CS has a permanent position with a good salary, regardless of whether they ever get another promotion or not. Some people do really care about the Full Professor title, but it's not mandatory that you take those further career steps particularly seriously.
A bigger issue post-tenure is the money side of things. Do you need significant funding to carry out the kind of research you want to do, e.g. because it needs reasonably expensive equipment or employee/minion labor? If yes, you do have to care what people with money think, whether it's funding agencies or corporate donors, and that constrains the research you can do. If no, e.g. because you work on your own projects and don't particularly need equipment or a large lab of minions (common in areas like theory and logic), then you don't really have to care about the funding agencies, either.
Interesting point of view, the problem in compiler construction is well known ("Proebsting's law", though it says it's more like 18 years instead of 10.)
The issue with benchmarks is surely well known, also by the PyPy authors; I wonder what the biggest application is that they have benchmarked or that runs on PyPy.
Your point on the JIT compiler interrupting program execution is certainly valid, too, but not necessarily so. One could easily do the code generation in a separate background thread and let execution switch over only if necessary. But, as you have already said, a latency issue certainly exists. This is one of the cases where interpreters usually have a leg up, and there are promising ways of optimizing interpreters.
Yes, you could do a background thread, with some caveats:
1. On most current CPU's, this will cause really bad cache/memory thrashing, enough to probably impact the program.
2. This may actually cause significant slowdown, depending on how long it takes to optimize a given set of code (IE it may be better to spend 100ms paused optimizing than 5000ms in the background). This is, of course, a latency issue.
3. State of the art for most JIT's is still to use one thread. The number of folks doing actual parallel code generation is nil. So sadly, even if you had 4 cores, 3 empty, you'll still, at best, get to use one of them for the background thread doing the optimizing. There are parts that are trivial to parallelize if you've structured the JIT "right", but they aren't always the parts that are slow.
Background compilation in a separate thread actually works pretty well. IE9 has been shipping it with Chakra for a while, and Firefox is now getting it (and it improved the benchmarks a lot, especially on ARM).
Good to hear it's gotten better. Admittedly, I wasn't thinking about browser based JITs when I said that :)
I'm actually curious if you have any stats on how much of the time this is being done on actual busy machines where it's going to compete for L1/etc resources vs how often it's able to be offloaded onto an otherwise empty core.
IE i expect their to be a significant difference in the use cases for JIT's like PyPy, which are probably going to sit on shared servers that folks are trying to maximize utilization of, vs desktops where I imagine most browsing probably doesn't use all cores at 100%.
No, AFAIK.
"Tiered compilation, introduced in Java SE 7, brings client startup speeds to the server VM.
...
Tiered compilation is now the default mode for the server VM. "
Again, AFAIK, the server VM still has a significantly different set of tuning than the client VM. In particular, it runs some significantly more complex opts that the client VM does not.
ad 1) Hm, this seems to be a good point, but what's with the following line of thinking: some thread A interprets a program P, while another thread B compiles P to native machine code (P'). Now, if another thread C would start executing P' (taking the data/snapshot from A), then C's caches should build up and remain accurate. Of course, if this happens too often, then the caching behavior will be shitty. I always wondered (based on my interest in interpretation), how much I-cache misses the instruction cache flushes after inline-caching in native machine code cause. (If you have some data on that, please let me know.)
ad 3) I am well aware of that. However, I remember that at PLDI'11 there was a talk from Univ. of Edinburgh chaps doing parallel trace-based dynamic binary translation. Obviously, DBT is less work than a high level, full-blown JIT, but at least it's not nil :)
I know these from the site, and have looked at the Django benchmark that's listed there. I think it's a rather small benchmark that does exercise lots of Django internals (but that benchmark comes from Unladden Swallow). I don't know for the twisted ones, though.
What I actually wanted to know, what the biggest application is, i.e., a not benchmark.
