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