monopede

Note that Dalvik is actually not a very good trace JIT. There's a recent paper comparing Dalvik to an embedded version of Hotspot. The Dalvik interpreter was slightly faster (~5%), but the JIT speedup was only 3-4x whereas it was ~12x for the method JIT. The reason is that Dalvik's traces are way too short and cannot even span method boundaries. That means little scope for optimisation and a lot of code just to load the state from the stack into registers and then write it back. Weirdly enough, Dalvik also generates more code than the method JIT, yet low amount of compilation overhead was their main goal.

Fortunately for Dalvik, most applications actually spend most of their time in native code.

The paper (behind ACM paywall): http://dl.acm.org/citation.cfm?doid=2388936.2388956

I don't think assemblers written in assembly were that bad. LuaJIT 2 uses direct threading (not new at all), register-based bytecode (relatively new), and manually optimised register assignment (perhaps new). AFAICT, the key innovations are that he did not use Lua 5.1's register-based bytecode format, but simplified it even further so it can be decoded efficiently on x86. The second key component is that he pre-decodes the following instruction in order to take advantage of out-of-order execution. This technique also required fixing some register's roles.

Don't get me wrong, I think LuaJIT2's interpreter is great, but interpreters before LuaJIT2 weren't complete crap, either. Many emulators, for example, have very good interpreters written in assembly (some aim to be cycle-accurate).

I was using the "bc" command line calculator. Turns out it's rounding the exponent. The revised number is correct, though.

Moore's law: Transistor count doubles every 18 months. Assuming 40 years at the company (it's a bit less) that's: 2^(40/1.5) = 67,108,864

The 62 Core Xeon Phi has 5 billion transistors. Divided by that number is: 149. That's a bit low. The Intel 8080 that came out in 1974 (when he joined the company) had 4,500 transistors. Looks like Moore's law has been slowing down a bit in recent years. Probably due to the focus on reduced energy usage.

EDIT: It works out if you replace "18 months" by "24 months". Revised value: 2^(38/2) = 524288. Impressive still.

Would make sense. Michael Bender is a co-author on that paper and he apparently works for Tokutek, judging by this presentation: http://www.bnl.gov/csc/seminars/abstracts/Bender_Presentatio...

As I understand this, this wouldn't automatically protect you from race conditions. If you have a shared variable x then a statement like

  x += 5

  x = somefunction(x)

  with thread.atomic:  x = somefunction(x)

That said, the fundamental problem is shared mutable state, and I don't see an easy way around that in Python. In that sense, this is probably easiest to work with.

"I'm thinking of doing a PhD in Germany"

I'm not discouraging, but once you're considering a particular position, please try and talk to previous PhD students of your prospective supervisor. Germany has hardly any fully-funded PhD positions. Instead you typically get employed as staff and have to combine that with your PhD work. The problem is, often professors take on lots of PhD students to get more funding and end up having hardly any time. I've heard stories of a professor having 8 or so PhD students that still wait on him to read their thesis and give the go-ahead for their viva (PhD defense). I'm not saying this is the case everywhere, but it's something to be aware of. So try and find out beforehand.

The blog author didn't actually have two factor authentication enabled. The headline is wrong.

Actually, she just spend a few weeks practising with an Olympic competitor, i.e., nowhere near 6 months. I'm not an expert on these things, but it seemed to vary from scene to scene. Someone commented on the trailer and explained how it's very accurate, but there were a few shots in the movie where what the expert explained seemed missing (like "kissing" the string).

You can build a library for doing Erlang-style programming, but there are lots of features that you can't reproduce.

(1) In C++ you may get hard crashes, so to get reliability you need to use high-overhead OS processes. Erlang allows you to hundreds of thousands (yes, really) of processes because they are really lightweight (76 words + heap/stack). Also, copying within the same address space has much lower overhead (no system call/context switch) and serialisation is much simpler.

(2) Because of immutable data you can do have nice fault tolerance as follows. Imagine you have a request handler function that takes a state and a request. However, the request is malformed or triggers a bug in the handler. In a language that doesn't enforce immutability you have to restart the handler process because the state may be in an inconsistent form. In Erlang you would just discard the request (or send an error message) and handle the next request with the unmodified state.

(3) Pattern matching makes receiving a message very convenient.

I probably forgot a few things, but this gives you an idea.

That depends on the kind of scientific computing you want to do.

Haskell has the repa library [1] which is very nice for working with (multi-dimensional) arrays at a high level. Performance is decent (I don't know if they have a BLAS/LAPACK binding). Overall, the main advantage of Haskell is its runtime system and its great support for concurrency. The downside is, it does not have OpenMP and the MPI bindings don't look very nice to use (I don't know how OCaml or SML fare in this area). There are OpenCL bindings, but I've never used them. Data parallel Haskell is still under heavy development, so that's probably going to take a few years to become production-ready.

OCaml's advantage is that C-like algorithms are easier to transcribe and use (no monads). OCaml's main disadvantage is that its runtime doesn't support multicore well (or even at all?). If you want that you can use F#, though.

I don't know anything about the current state of SML implementations.

[1] http://www.haskell.org/haskellwiki/Numeric_Haskell:_A_Repa_T...

Small correction: "Plankalkül" which translates to "plan calculus"

Or create a (resizeable) image that is case-sensitive. Not sure what the performance overheads of that will be, though.

I think he/she meant that birds can't survive in space. The pigs at least seem to have some sort of bowl around their head.

Note that in many dynamic languages (and I think that includes PHP), syntax checking is done right before you try to run it, and type checking is performed at runtime. When you're programming in a Java IDE, these kinds of errors (and related ones, like typos in variable names, etc.) all get resolved while you're typing. In PHP or JavaScript you only find out once you run the program, so saving 3 seconds can be a huge win.

Of course, you can do static analysis to some degree which would cut down that time even further, but you may also get false alerts or miss some issues.

Yes, for the AI class they promised to give you a signed statement of accomplishment. IIRC, this statement will also tell you how well you did in relation to all other students (including Stanford students).

Well said! I don't think I found a argument in that article that I would agree with. The mentioning of Perl as a great example is probably the worst. The purpose of a programming language is to express things as precisely as possible, both to a computer and to a human. Perl's extreme context-sensitivity is what I dislike most about it.

Regarding Unicode support, I see it having some advantages, but current editors don't support Unicode input well. Emacs has an input mode where you can type \alpha and it replaces it with the appropriate unicode character, but I haven't seen any other editors with support for that. For some more obscure symbols, it can also be difficult to find out how to input them.

I'm wondering whether that article is actually meant seriously -- some of these claims are just so absurd.

That will most likely bite you since you're giving a pure type to a non-referentially transparent function. There is a reason why random functions are in a state monad or IO.

That's very easy to explain. A low-pause GC requires a concurrent garbage collector. Writing a correct concurrent garbage collector is VERY tricky, so you usually start with something much simpler. Concurrent GCs typically also add overhead to the mutator (the user program), so it tends to be a trade-off of high throughput vs. short maximum pause times. As an example Java's G1 collector ("Garbage First") took a team of experts about 5 years to get correct.

OTOH, writing a standard (single-threaded) Cheney-style copying GC can be done in a few days. Actually, the more time consuming part for me was to get all the pointer information to the GC.

Sorry to break the stream of cheers, but I have my concerns about this design. Yes, it's a neat idea and already quite well-implemented. Looking at the video I can't help but feel confused. Sometimes things seem to resize randomly (at places where there is no cursor shown -- is there an input not shown?) and I have my doubts what "normal" users would do. I strongly recommend that you do grab a few people with medium technical background and ask them to perform a few tasks and then just observer (no helping). That should quickly tell you where (if) people get lost. Good work overall, but keep refining.

Hm, this doesn't mention support for lexical closures (not turned on by default, of course) which supposedly has been merged into the master branch. I sure hope this will make it into the release.

There is an interesting book, "The Spirit Level: Why Equality is Better for Everyone" by Richard Wilkinson and Kate Pickett, that makes a very strong argument that in developed countries inequality is correlated pretty much every "bad" metric (health, crime, teenage pregnancy, etc.) of a society.

Now, of course, correlation does not mean causation and it's perhaps more interesting what the true underlying causes are. But if inequality is such a strong indicator, it is worth wondering whether inequality isn't a bad thing in itself.

I understand that this is meant just as an experience report, but I have to say this article didn't convince me in any way that this rewrite was a good idea. Obvious questions:

1. How does the performance of the new system compare to the old system?

2. What exactly were those maintenance issues with the Erlang server? Did just no-one in your team find the time to learn Erlang well enough? I know Erlang isn't the prettiest of languages, but async I/O isn't the only advantage of Erlang. A battle-tested concurrent runtime and built-in support for fault-tolerance are two obvious examples.

English is my second language and I got ~13,500 words. I was surprised that this was only half the average. I read a lot of scientific papers in my field and almost never come across a word I don't know. Writing technical papers well also requires not much vocabulary (it's more about clarity of expression). I believe to get beyond that number you simply have to read lots of books. I notice lots of words I've never heard of when reading, say, Bill Bryson but I very rarely bother to look them up because they usually make enough sense from the context.

Given that some people have separate accounts for games, I wonder how accurately that number reflects the actual number of users.

Looking at the instruction set it doesn't even support subroutines. It would only need a way to get and set the current program counter (like ARM) and you could implement subroutine calls using push, pop, and jmp.

Actually, there are microkernels running in a vast amount of mobile phones nowadays. They typically don't run on the main CPU, though, but on various controller chips.

Microkernels are practical -- they just have different trade-offs. Microkernels are preferable if (a) the whole Linux kernel would be too large, or (b) you consider security more important than performance. It's probably also easier to provide realtime services with Microkernels, but I don't know much about Linux' realtime API to know if Microkernels would be much better here.

In the video he mentions it's about 5000 per night.

Both have a hostile attitude towards privacy, claiming that it's dead, trying to make it look old fashioned and irrelevant. [Citation Required]

Actually he bought Pixar to turn it into a hardware company. John Lasseter is probably the bigger reason why it became such a successful animation company. Of course, thanks to Steve the company survived long enough to discover its true purpose and thanks to Steve got such a great deal with Disney for marketing the initial movies.