monopede · HackerTrans

monopede

no profile record

comments

14 ปีที่แล้วdiscuss

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

14 ปีที่แล้วdiscuss

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).

14 ปีที่แล้วdiscuss

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

14 ปีที่แล้วdiscuss

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.

14 ปีที่แล้วdiscuss

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...

14 ปีที่แล้วdiscuss

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

may be fine depending on whether it is implemented as a single bytecode instruction or not. However, more complicated updates are still subject to races:

  x = somefunction(x)

It is only safe if you use:

  with thread.atomic:  x = somefunction(x)

Having a serialisation doesn't mean it's the right serialisation.

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.

14 ปีที่แล้วdiscuss

"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.

14 ปีที่แล้วdiscuss

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

14 ปีที่แล้วdiscuss

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).

14 ปีที่แล้วdiscuss

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.

14 ปีที่แล้วdiscuss

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...

14 ปีที่แล้วdiscuss

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

14 ปีที่แล้วdiscuss

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

14 ปีที่แล้วdiscuss

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.

15 ปีที่แล้วdiscuss

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.

15 ปีที่แล้วdiscuss

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).

15 ปีที่แล้วdiscuss

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.

15 ปีที่แล้วdiscuss

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.

15 ปีที่แล้วdiscuss

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.

15 ปีที่แล้วdiscuss

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.