41–50 of 69 posts
I'm curious because I'm trying to find an example of a "non-scalar" programming language, a la this attempt here[1].
Thanks for the help!
So, sorry to change the subject away from pi, but how does Julia do on the code-gen end? Are we talking SIMD type optimizations? Are there hooks in the language for tuning hot-code? I'm curious because I'm trying to find an example of a "non-scalar" programming language, a la this attempt here[1]. Thanks for the help! [1] https://news.ycombinator.com/item?id=13867574
Earlier quoted context omitted.
> I like Julia because it's extremely fast ...compared to Python, under some circumstances, disregarding startup time. Don't oversell it. Don't confuse what Julia aspires to be with what it is , or you'll just turn people off when they feel they've been misled. There are extremely fast ahead-of-time-compiled languages that would have finished their computation while Julia is still JIT-ing its kernel.
Julia startup time is 0.5 seconds on a very weak laptop. That's comparable to the JVM, which is nevertheless fairly popular. You may not want to write command line tools in Julia, but there's not much else that's a serious problem since process startup time is rarely that big of a performance issue. Disregarding JIT time, Julia is as fast as compiled languages – we benchmark against C and Fortran and don't grade on a…
The time to parse the data I needed was many minutes, slower than Python. Restarting a Jupyter kernel would break my flow every time.
The benchmarks are all for numerical computing, where the hard work is typically offloaded to a BLAS library anyway, and don't involve strings or dictionaries. Let's see a JSON parser in there and not just a Mandelbrot set.
I have always been skeptical about 'scientific' languages. Why do you need a special language when any general language + some libraries will do? This is a good example of a feature that only really makes sense in a scientific language.
In R, I can import a CSV, plot a histogram of each column, and fit a linear regression of one column against the others in about 5 minutes and 15 lines of code. In Python, I can do the same thing if I install the Pandas and Statsmodels libraries first. Try that in Ruby, Perl, C++, C, Java, Rust, Haskell, Common Lisp, or just about any language you can think of. Good luck.
Most times a julialang.org blog post is posted to HN, I wonder whether the choice of content is well chosen to spread awareness of and interest in Julia. I write this as a huge Julia fan; I use Julia daily, and it is both my favorite language and the language I know best. So I already think Julia is great. But reading many Julia blogs, especially those from julialang.org, would make me think Julia is only useful for…
What's your working setup with Julia? I'm looking at switching over from MATLAB as soon as the semester is over.
On a 4-core CPU I have the environment variable JULIA_NUM_THREADS set to 3 so that when Julia is doing threaded worked there's still a core free for web browsing.
One potential gotcha: the Julia docs will mention that you can access shell commands from the REPL by starting your line with a semicolon, e.g. ;ls. For me this only works if you start Julia from something like Git Bash, not cmd.
Lots of people seem to like Juno (junolab.org) as an IDE. The team behind it has made incredible progress recently, and sometimes I use it for its GUI around the debugger, but for the most part I tend to stick to Notepad++.
Earlier quoted context omitted.
Are you asking "why do we use scientific languages"? If that's your question, the answer is the same reason that you don't write a webserver in assembly. If you're asking "why Julia versus other languages" it's that, well, Julia is fighting to answer that question for itself. As far as I can tell: - Versus R and Octave: performance, coherent syntax, and more features for writing "programs" instead of just "scripts" -…
Are you aware that can call R and Python from Julia with practically no overhead? And I mean that both in performance and expressiveness?
edit: looked up "call R from Julia", it looks like there's a n "RJulia" library for this. Assuming there's a Python equivalent? How does this compare to, say, using RPy2 in Python (which is nice but kind of annoying)?
Earlier quoted context omitted.
Julia startup time is 0.5 seconds on a very weak laptop. That's comparable to the JVM, which is nevertheless fairly popular. You may not want to write command line tools in Julia, but there's not much else that's a serious problem since process startup time is rarely that big of a performance issue. Disregarding JIT time, Julia is as fast as compiled languages – we benchmark against C and Fortran and don't grade on a…
When I last used it, the time to import even two modules was many seconds. I know that's JIT time, but that breaks the flow of developing with Julia like it's a dynamic language. And the JVM is popular, yes, but nobody would call it "extremely fast", particularly for interactive use, because of its startup time. The time to parse the data I needed was many minutes, slower than Python. Restarting a Jupyter kernel woul…
Earlier quoted context omitted.
Are you aware that can call R and Python from Julia with practically no overhead? And I mean that both in performance and expressiveness?
I didn't know this. Will look into it, thanks! edit: looked up "call R from Julia", it looks like there's a n "RJulia" library for this. Assuming there's a Python equivalent? How does this compare to, say, using RPy2 in Python (which is nice but kind of annoying)?
You want RCall.jl and PyCall.jl. Both allow you to directly work with and manipulate native objects. RCall even allows you to bring up an R REPL.
Earlier quoted context omitted.
"Why do we use scientific languages?" is very true. Applause to the Julia contributors for their work on this innovative language with great out of the box support for modern computer chip architectures. However, they have fibbed to build up momentum, particularly their performance benchmarks. The tests are of compiled Julia with OpenBLAS for the benchmarks against out of the box versions of the other languages. Also…
We use whatever BLAS is linked to in a commonly available official distribution. Julia was one of the first to take this seriously and bundle a high performance BLAS as the default - and I think more projects are following our lead and doing the same. Also, only one benchmark actually uses BLAS. As for co-ordination on Julia posts - there is none. We submit all our blog posts to HN, and while some do reach the front…
Wonderful.
Insightful :)
Earlier quoted context omitted.
We use whatever BLAS is linked to in a commonly available official distribution. Julia was one of the first to take this seriously and bundle a high performance BLAS as the default - and I think more projects are following our lead and doing the same. Also, only one benchmark actually uses BLAS. As for co-ordination on Julia posts - there is none. We submit all our blog posts to HN, and while some do reach the front…
It would be interesting to see what happens if each language is compiled to the benchmark server, linked to the same BLAS and an expert implementation of the tests in each language was allowed; a scientifically valuable experiment. Just to remove all doubt about the relativities of performance :-) Wonderful. Insightful :)
It all depends on what you want to measure. The whole point of the micro-benchmark suite is to test very specific language primitives. I'd argue that the current set of benchmarks are more valuable for that than an "expert" implementation would be — that may end up simply testing the cleverness or resourcefulness of the expert.
1. https://github.com/JuliaLang/julia/blob/64409a0cae8b52d3f795...