>From browsing issues, it looks like the HttpServer.jl performance issue you referenced below should be now fixed by https://github.com/JuliaWeb/HttpServer.jl/pull/59.
On Fri, Sep 25, 2015 at 5:47 AM Páll Haraldsson <pall.haralds...@gmail.com> wrote: > On Thursday, September 24, 2015 at 11:07:56 PM UTC, Andrei Zh wrote: >> >> >> >>> I find this statement highly surprising.. wander if you meant to reverse >>> this.. My quant friend who had worked for years in Python had trouble >>> parallelizing Python code (may be resolved now..). I'm not familiar with R, >>> but Python has the GIL and associated problems. I also thought Erlang was >>> best-in-class (for concurrent, not "parallel"). >>> >> >> Oops, you are right, it's exactly the opposite. Consider it a result of >> quick answer between 2 meetings. Julia's capabilities are much better for >> concurrent and parallel programming than these in Python or R. >> > > But "probably comparable with Erlang" was not an error, taken > conservatively, you are probably talking about what pure benchmark numbers > of concurrency (only) might indicate. I believe Erlang has more (than > speed) currently not in Julia, while not better for non-concurrency related. > > >> For those in the Java/Scala world, I'm less sure about reusing that, I >>> know you can with JavaCall.jl, but understand there are bugs and >>> limitations to it. >> >> >> Unfortunately, that's true. @aviks has made a great work connecting Julia >> to JVMs via Java Native Interface, but as far as I can see, JNI is shitty >> by itself, and it's very hard to to make integration between Julia and Java >> really stable. >> > > Even if this would work perfectly, I'm not sure (most) Julia (or Java?) > users would want to mix (I guess ok for truly good/critical libraries..) at > least for GUI/enterprise applications.. At least for me, it seems involving > a JVM or any VM, is outdated.. Yes, Julia has LLVM, but it's not the same. > >> >> "HttpServer.jl, has low latency 0.5 ms and high throughput (latency on >>> the same order of Python's Flask and Scala's Spray mature frameworks, and >>> throughput also comparable[82])." >> >> >> That's funny, because specified reference leads to an issue on >> performance that was opened by me and incorrectly interpreted by the author >> of Wikipedia page. At that test Julia outperformed Flask, but was still 3-6 >> times slower than Spray. >> > > > Good throughput, but very high latency > https://github.com/JuliaWeb/HttpServer.jl/issues/48 > "At the same time, with even very naive test in Python (using requests > library) I was able to get 1.3ms, and with Julia (Requests.jl) it was even > lower - about 0.5ms per request." > > Then the issue was closed. It seems Julia can have low latency (are Flask > and Splay [numbers, for it and throughput] considered best-in-class, at > least for those language?). Splay has "< 1 ms" so unclear how much better, > it may be. It seems you do not dispute the low latency claim of Julia [on > the WP page] (any more)? > > Do you only disagree, then only, with the "high throughput" of > Julia/[HttpServer.jl] (and would only change high->good)? [With 1000 > threads] Julia beats Flask, "comparable", while a third of Splay. Maybe > within an order of magnitude is not comparable.. Not sure about the 6 times > slower number. > > I haven't looked to closely at Requests.jl, so I do not know the > differences between it and HttpServer.jl are other libraries. It really > only matters that one library gets good throughput and then you can use > that one? > > > >> Seems like I need to repeat my tests to get latest results. >> > > It would be interesting to know if the numbers have improved.. > > >> I didn't check if this works the same, or just similarly? >> >> >> They have totally different APIs and approaches in general. The main >> point is that if you want to keep it working with updated version of Julia >> and libraries, you have to adapt web application too. And it's really not >> funny to come back to a code written half a year ago just because libraries >> it used are now deprecated. >> > > Yes, see your point.. I guess the stuff still works it it ever did.. I see > for plots that there is a generic package that is supposed to hide the > differences of six (by now) different plotting packages.. You say the API > is totally different, I wander how difficult or stupid it is to support old > APIs here in some way.. >
