Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JNumPy: Writing high-performance C extensions for Python in minutes

github.com

Post reply on HN
Print view View original

61–66 of 66 posts

Re: JNumPy: Writing high-performance C extensions for Python in minutes

#61

Post by JZerf »

adgjlsfhk1 wrote: post #60
JZerf wrote: post #59

Earlier quoted context omitted.

Thanks, I hadn't noticed that Julia was also doing compilation during the benchmarking and I'm curious if it would be hard to get those benchmarks to be done with PackageCompiler.jl. With that being said, the memory usage still seems very high. For many of the problems, Julia is often using the second most memory of all the programming language implementations being benchmarked and several of those other programming…

In the past the benchmarkgame people haven't let us use PackageCompiler. The big memory gain would be that you could skip loading things like LinearAlgebra and the other standard libraries that aren't being used (but which you are still loading code for).

I think some more effort should be made in getting the default memory usage down to a more reasonable level. This site https://programming-language-benchmarks.vercel.app/problem/h... shows a simple Hello World Julia program as using 169 MB of memory (and I saw similar memory usage on my computer running '/usr/bin/time julia -e 'println("Hello World!")'') which was the third worse of all the programming language implementations that were tested.

Re: JNumPy: Writing high-performance C extensions for Python in minutes

#62

Post by Sukera »

JZerf wrote: post #59
ChrisRackauckas wrote: post #57

Earlier quoted context omitted.

Remember that for those benchmarks, C, C++, and Rust compile the binaries and then run the benchmark, while Julia compiles as part of the benchmark. The memory usage is dramatically decreased if you do a workflow similar to the other languages using something like PackageCompiler.jl to build a binary that is benchmarked. If you treat the other languages as "JIT" and include those factors in the benchmarking process,…

Thanks, I hadn't noticed that Julia was also doing compilation during the benchmarking and I'm curious if it would be hard to get those benchmarks to be done with PackageCompiler.jl. With that being said, the memory usage still seems very high. For many of the problems, Julia is often using the second most memory of all the programming language implementations being benchmarked and several of those other programming…

Yes, the size in memory is definitely an issue. Do keep in mind that right now, the julia executable more or less just has to load all of LLVM as a shared object into memory, since we might compile stuff at any time. That alone adds ~84M of overhead on my machine for the current libLLVM14 shared object. There's probably some other stuff I haven't thought of OTOH. The (non-minified) runtime itself is 244K at the moment, which can probably be slimmed down further. There are currently efforts underway to statically compile more stuff and hopefully introduce a more traditional static linking approach, but it takes time & lots of effort.

Still, a large chunk of the memory being spent is not in the code that's produced or in the allocations happening in the code, but libraries that are loaded but not required. It's one of the downsides of focusing on interactivity first. The benchmarks in benchmarksgame don't reflect that, which I guess is up to interpretation/what's required - if the total amount of memory is a concern it's an important figure, if you only care about your core algorithm not having inherent allocation/memory problems, you probably won't care about the compiler chain as much.

Re: JNumPy: Writing high-performance C extensions for Python in minutes

#63

Post by adgjlsfhk1 »

JZerf wrote: post #61
adgjlsfhk1 wrote: post #60

Earlier quoted context omitted.

In the past the benchmarkgame people haven't let us use PackageCompiler. The big memory gain would be that you could skip loading things like LinearAlgebra and the other standard libraries that aren't being used (but which you are still loading code for).

I think some more effort should be made in getting the default memory usage down to a more reasonable level. This site https://programming-language-benchmarks.vercel.app/problem/h... shows a simple Hello World Julia program as using 169 MB of memory (and I saw similar memory usage on my computer running '/usr/bin/time julia -e 'println("Hello World!")'') which was the third worse of all the programming language imple…

Absolutely! This isn't high priority but there is some very low hanging fruit. It's not that reducible though since llvm is 84 of those megs and they have to go into memory if you want to be able to generate new code.

Re: JNumPy: Writing high-performance C extensions for Python in minutes

#64

Post by ChrisRackauckas »

JZerf wrote: post #61
adgjlsfhk1 wrote: post #60

Earlier quoted context omitted.

In the past the benchmarkgame people haven't let us use PackageCompiler. The big memory gain would be that you could skip loading things like LinearAlgebra and the other standard libraries that aren't being used (but which you are still loading code for).

I think some more effort should be made in getting the default memory usage down to a more reasonable level. This site https://programming-language-benchmarks.vercel.app/problem/h... shows a simple Hello World Julia program as using 169 MB of memory (and I saw similar memory usage on my computer running '/usr/bin/time julia -e 'println("Hello World!")'') which was the third worse of all the programming language imple…

Oh definitely agreed. A lot of this is because Julia always loads BLAS and LLVM, so it's like doing `import numpy; import numba; print("Hello World")` and then noticing most of the startup time is loading numpy and numba. But it's a hard question because if BLAS isn't always loaded with Julia, its previously core scientific computing case is impacted. As it has been growing to be more widely used in a general purpose case, these kinds of assumptions are having to be revisited.

One can of course remove this in the compilation stage of PackageCompiler because PackageCompiler builds a new system image, and where BLAS is loaded is in the system image, so you can create a new from-scratch system image that is more lean. However, the tooling isn't quite there yet: right now the main way that's documented is something that extends the default system image, hence the large binaries. There's StaticCompiler.jl which does tree shaking so it makes small binaries, but it doesn't support most of the Julia runtime right now so it's limited in the codes it can handle. So right now the foundation all exists and it's at a usable state but definitely needs to improve.

Re: JNumPy: Writing high-performance C extensions for Python in minutes

#65

Post by melony »

machinekob wrote: post #39
lraxl wrote: post #35

Earlier quoted context omitted.

It will yield a small speedup ( Microsoft is misallocating its resources. The scientific ecosystem should be ported to .NET, with first class support for F#.

They already try it like 2/3 times and it didnt take off so why should it be different today?

Everytime they did it, it was half baked at best. Scientific libraries need driver support, Microsoft always takes the happy path and ignores all the other hardware permutations. If you are not running Intel/Nvidia in a Win32 environment you are out of luck. WSL2, ARM, AMD, etc. don't have much synergy in terms of product support.

Re: JNumPy: Writing high-performance C extensions for Python in minutes

#66

Post by cycomanic »

meta2meta wrote: post #30
cycomanic wrote: post #24

Earlier quoted context omitted.

I did a comparison of Julia vs numpy, cython and pythran [1] some time ago, for a typical dsp routine we use in our work, and Julia was quite a bit slower than the alternatives. Now I'm by no means a Julia expert so I might have missed an optimisation opportunity (although I posted this and nobody could point to something obvious) , however the whole advertisement behind Julia is that one gets essentially C speed wit…

You should run Julia code directly to benchmark instead of calling it in Python through pyjulia.

Actually I benchmarked inside Julia as well and didn't see a difference so left it like this.
Post reply on HN