Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It should be pretty obvious that something is amiss here.

Erlang is usually not the fastest language for (purely) CPU-bound tasks, of which this is the case. But being 34 times slower than a Javascript engine tells you that something is not done right. In fact, there is an interesting alternative program which is only a factor of 2 slower. I would expect it to be slower since regular expression handling is something you rarely do in Erlang on critical paths. But 34 times slower is way above target - and that tells me something is going wrong in a deep way in that code. Also in the real world you are allowed to cheat on heavyweight computation, luckily. Write it in C, Ocaml, OpenCL, CUDA, GHC+DPH+REPA or what have you. Then use Erlang to manage the data as payload and move it around.

I have no knowledge of HiPE. At least not enough to write a blog post on how it works right now. I would have to study it a bit before I can do that. There are plans for an alternative JIT'ed backend for Erlang though. That said, I don't think Erlang will ever be "fast" since the language isn't statically typed, and there is currently no provision for type annotations.

The main reason for having a JIT for Erlang would be that more of the runtime can be written in Erlang, which makes the system more portable. This is almost always a win.



So javascript is actually the fastest implementation of regular expressions, so I'm not sure why something's "obviously amiss."


the factor of 34 is. (and that there is a program with only factor 2 suggests that as well.)


How does "the factor of 34" tell us that something's "obviously amiss"?

Maybe that's more than you expected, but incredulity is a weak argument.

Why does there being "a program with only factor 2" suggest that something's "obviously amiss"?

Maybe that program does not use regular expressions for all the substitutions.

https://alioth.debian.org/forum/forum.php?thread_id=14805...


>> It should be pretty obvious that something is amiss here. ... 34 times slower is way above target - and that tells me something is going wrong in a deep way in that code. <<

Please tell us what is "going wrong in a deep way".


Intellectual dishonesty is certainly wrong in a deep way.

Several of us here obviously have our jaws dropping thinking: "What!? 34 times slower when typically perfs are quit ok, what is going on here?!"

Where do you put the limit? You realize that your "counter argument" makes no sense.

918 times slower? Would that be enough?

What about 8734 times slower?

Where do you draw the line?

Why do you keep insisting saying that "34 times slower" is "nothing to see here, move along"?

What about 1923408130294870918234 times slower? Would that be enough for you to consider something may be wrong?


>>"What!? 34 times slower when typically perfs are quit ok, what is going on here?!"<<

"perfs" to do what exactly are "quit ok"?

Please show us your regex processing Erlang program and your time measurements.

---

fyi exactly the same C program can 3,600 times longer using a C interpreter than when using GCC.

http://benchmarksgame.alioth.debian.org/u32/program.php?test...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: