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

Julia Computing raises $24M Series A

hpcwire.com

Post reply on HN
Print view View original

121–130 of 246 posts

Re: Julia Computing raises $24M Series A

#121

Post by spywaregorilla »

f6v wrote: post #107
mr_overalls wrote: post #76

Earlier quoted context omitted.

Right. R's killer feature is its ecosystem. I'm wondering if most statisticians or researchers deal with data big enough that massively better performance would be enough motivation to switch.

You can write fast software with R, you just need to know how. The same applies to Julia - not everyone knows how to develop high-performance code.

> You can write fast software with R, you just need to know how.

When the trick to writing fast R code is to rely on C as much as possible, that feels less compelling.

Re: Julia Computing raises $24M Series A

#122

Post by infogulch »

Congrats!

I tried Julia for the first time last week and it was great.

I've been playing with the idea of defining a hash function for lists that can be composed with other hashes to find the hash of the concatenation of the lists. I tried to do this with matrix multiplication of the hash of each list item, but with integer mod 256 elements random matrices are very likely to be singular and after enough multiplications degenerates to the zero matrix. However, with finite field (aka Galois fields) elements, such a matrix is much more likely to be invertible and therefore not degenerate. But I don't really know anything about finite fields, so how should I approach it? Here's where Julia comes in: with some help I was able to combine two libraries, LinearAlgebraX.jl which has functions for matrices with exact elements, with GaloisFields.jl which implements many types of GF, and wrote up a working demo implementation of this "list hash" idea in a Pluto.jl [2] notebook and published it [0] (and a question on SO [1]) after a few days without having any Julia experience at all. Julia seems pretty approachable, has great libraries, and is very powerful (I was even able to do a simple multithreaded implementation in 5 lines).

[0]: https://blog.infogulch.com/2021/07/15/Merklist-GF.html

[1]: https://crypto.stackexchange.com/questions/92139/using-rando...

[2]: https://github.com/fonsp/Pluto.jl

Re: Julia Computing raises $24M Series A

#123

Post by spywaregorilla »

I played with Julia a bit in grad school. Although I didn't end up using it much after that I thought it was a lovely language. Forget python, I hope Julia manages to kill off Matlab and its weird stranglehold on various pockets of academia. Congrats to the team here.

Re: Julia Computing raises $24M Series A

#124

Post by KenoFischer »

p_j_w wrote: post #116
KenoFischer wrote: post #37

Earlier quoted context omitted.

Yes, software-defined radio, we have a very broad set of interests, and that happens to be one of the open jobs :).

Understandable if you can't answer this question, but how much work have you guys done with SDRs and arrays?

This project is just starting, so I have hardware sitting on my desk and have used it a bit, but other than that not much.

Re: Julia Computing raises $24M Series A

#125

Post by nojito »

mbauman wrote: post #97
tylermw wrote: post #93

Earlier quoted context omitted.

"Massively better performance" is a bit misleading: Julia is only massively better at certain workflows. The fastest data.frame library in ALL interpreted languages is consistently data.table, which is R. For in-memory data analysis, Julia will have to offer more than performance to win over statisticians/researchers. Benchmarks: https://www.ritchievink.com/blog/2021/02/28/i-wrote-one-of-t...

> The fastest data.frame library in ALL interpreted languages is consistently data.table, which is R. DataFrames.jl is very rapidly catching up and starting to surpass it. After hitting a stable v1.0 they've begun focusing on performance and those benchmarks have changed significantly over the past three months. Here's the live view: https://h2oai.github.io/db-benchmark/

40% slower in groupbys and 4x slower in joins isn’t convincing.

Re: Julia Computing raises $24M Series A

#126

Post by snicker7 »

tylermw wrote: post #93
mr_overalls wrote: post #76

Earlier quoted context omitted.

Right. R's killer feature is its ecosystem. I'm wondering if most statisticians or researchers deal with data big enough that massively better performance would be enough motivation to switch.

"Massively better performance" is a bit misleading: Julia is only massively better at certain workflows. The fastest data.frame library in ALL interpreted languages is consistently data.table, which is R. For in-memory data analysis, Julia will have to offer more than performance to win over statisticians/researchers. Benchmarks: https://www.ritchievink.com/blog/2021/02/28/i-wrote-one-of-t...

As another commenter pointed out, DataFrames.jl is already faster than data.table in some benchmarks.

And that's the killer feature of Julia. It is easier to micro-optimize Julia code than any other language, static or dynamic. Meaning if Julia is not best-in-class in a certain algorithm, it will soon.

Re: Julia Computing raises $24M Series A

#127

Post by p_j_w »

KenoFischer wrote: post #124
p_j_w wrote: post #116

Earlier quoted context omitted.

Understandable if you can't answer this question, but how much work have you guys done with SDRs and arrays?

This project is just starting, so I have hardware sitting on my desk and have used it a bit, but other than that not much.

I see. Well I wish you guys luck on that!

Re: Julia Computing raises $24M Series A

#128

Post by tylermw »

spywaregorilla wrote: post #121
f6v wrote: post #107

Earlier quoted context omitted.

You can write fast software with R, you just need to know how. The same applies to Julia - not everyone knows how to develop high-performance code.

> You can write fast software with R, you just need to know how. When the trick to writing fast R code is to rely on C as much as possible, that feels less compelling.

While writing in C is one way to speed up R code, you can also get pretty close to compiled speed by writing fully vectorized R code and pre-allocating vectors. The R REPL is just a thin wrapper over a bunch of C functions, and a careful programmer can ensure that allocation and copy operations (the slow bits) are kept to a minimum.

Re: Julia Computing raises $24M Series A

#129

Post by amkkma »

tylermw wrote: post #117
amkkma wrote: post #104

Earlier quoted context omitted.

In addition to the comment about df.jl catching up, they aren't comparable at all. Julia's DF library is generic and allows user defined ops and types. You can put in GPU vectors, distributed vectors, custom number types etc. Julia optimizes all this stuff. data.frame is just a giant chunk of c (c++) code that one must interact with in very specific ways

> Julia's DF library is generic and allows user defined ops and types. You can put in GPU vectors, distributed vectors, custom number types etc. Julia optimizes all this stuff. These features aren't of interest to practicing statisticians, which the parent comment was talking about. > data.frame is just a giant chunk of c (c++) code that one must interact with in very specific ways I don't understand this criticism:…

>These features aren't of interest to practicing statisticians, which the parent comment was talking about.

It's pretty convenient for things like uncertainty propagation and data cleaning...all things statisticians should care about.

>I don't understand this criticism: yes, data.table has an API

A relatively limited API, walled off from the rest of the language.

Re: Julia Computing raises $24M Series A

#130

Post by krastanov »

tylermw wrote: post #83
krastanov wrote: post #50

Earlier quoted context omitted.

Interoperability between libraries that expect your code to be pure R / pure Python. If you use RCpp or Cython or CPython then you lose much of the magic behind the language that enables the cool (but frequently slow) features. My biggest pain point in this situation: you can not use SciPy or Pillow or Cython code with Jax/Pytorch/Tensorflow (except in very limited fashion). Differential equation solvers that need to…

Once your Rcpp code is compiled, it's almost indistinguishable from base R (when you're calling it). All R functions eventually end up calling R primitives written in C, and Rcpp just simplifies the process of writing and linking C/C++ code into the R interpreter. The only difficulty with Rcpp-based R packages is you have to ensure the target system can compile the code, which means having a suitable compiler availab…

I wonder how much does it differ from python's use of C or Cython (I have only superficial R skills). The prototypical example of why Python's C prevents interoperability is how the introspection needed by Jax or Tensorflow (e.g. for automatic GPU usage or automatic differentiation) fails when working on Scipy functions implemented in C.

For instance, I imagine there is an R library that makes it easy to automatically run R code on a GPU. Can that library also work with Rcpp functions?

Post reply on HN