Hacker News Reader

Comment by agounaris | Hacker News Reader

Julia is a very interesting language but big data processing is not a matter of the programming language itself, but how your platform and your architecture is put together.

And nearly always your bottleneck is not the language itself..

View on HN

Depends on whether you're optimizing for latency or throughput - and of course, in some systems, that decision changes on an instant-to-instant basis. For throughput, indexing and shuffling is probably going to be the bottleneck, and that's dependent on network and filesystem I/O. But for the low-latency path, choice of language absolutely matters, so if you want to be able to share code between the two you end up needing both a fast language and fast architecture.

I think that if this were true, the data science libraries in Python wouldn't all be written in C under the hood, linking to Fortran, etc. Language can have a huge impact on performance with big data.

Julia is just a small step forward. It still has performance problems where the JIT can't help much - like the DataFrame structure, which is effectively a black box and therefor hard to optimize.

If you need performance on these kind of structures, you can use structured arrays in python.

The main reason I like the idea of Julia is that I don't see the problem of parallelism being addressed in python, at least not without cumbersome libraries (disclaimer: I haven't tried dask yet). If python had an equivalent to

    #pragma omp parallel for

I wouldn't have Julia ready in mind for my next project that requires creating a high performance algorithm.

This is not quite accurate as stated: the problem is the combination of a data structure that is not amenable to type inference with an API that would only be efficient if type inference had perfect knowledge of the contents of a DataFrame. There is a lot of work being done to develop a new API that has none of these problems and provides very high performance, which demonstrates that Julia's JIT is up to the task so long as you choose an appropriate API. Julia, like any language, has intrinsic limitations, but this is not a good example: it's an example of how good API design for Julia differs from good API design for other systems.

> This is not quite accurate as stated: the problem is the combination of a data structure that is not amenable to type inference with an API that would only be efficient if type inference had perfect knowledge of the contents of a DataFrame.

Sorry if I implied otherwise - what I meant is that the current DF structure is hard for the JIT to optimize, not that this is a fundamental limitation of Julia. Just that JIT's are limited. I shouldn't have said Julia is only a small step forward, I think. A JIT gets you a long way.

> There is a lot of work being done to develop a new API that has none of these problems and provides very high performance, which demonstrates that Julia's JIT is up to the task so long as you choose an appropriate API.

Can you link to information on this? I'd love to see information on the design around this.

>Can you link to information on this?

This blog post is a good starting point on the current shortcomings and design solutions of dataframes in Julia: http://julialang.org/blog/2016/10/StructuredQueries

Thanks a lot.

JIT's can only do so much by themselves, but the addition of generated functions in Julia gives the ability for library developers to modify generated code just before execution. It's almost like having a fully programmable compiler chain with a fraction of the work or effort.

Here's to hoping it'll be put to good usage!

Python numerical libraries links to LAPACK/BLAS/etc because that's how people used to do scientific computing before Python. Also for scientific computing you're mostly CPU bound which means that no one would use Python if the libraries were slower than Fortran or C. But big data problems are different in the sense that you're typically bound by IO, so while it certainly helps to have fast code it wouldn't be the first problem you'd want to solve.

I would say they link to LAPACK/BLAS because there's nothing to touch the combination of speed and robustness they provide.

It depends on what kind of data you're working with and what kind of operations you perform on it. If protein folding, then that's computationally expensive and the language will matter, doing mapreduce jobs, language matters little as the network overhead is going to be your bottleneck in a distributed environment.

I agree that this is generally true, but Finance is sort of a special case. In a world where firms pay the premium for colocated servers and direct data feeds in order to shave off a few milliseconds of latency there is also a strong push to use the vary fastest language possible + have the very best possible architecture, all to shave off as many extra milliseconds as possible.

That's only true for a very niche sort of trading (only high-frequency/latency arbitrage type stuff) which makes up a tiny portion of the financial industry[1]—and that tiny portion is certainly not using Julia for production trading systems.

Everyone else has more reasonable performance constraints.

[1]: I can't find my source right now, but I remember seeing a credible estimate that the HFT industry in the US takes in $10 billion in revenue. That's a drop in the bucket of an industry that's measured in trillions just in the US.

Intuitively this makes a lot of sense because HFT strategies make a tiny amount of money per trade and have to do a ton of trades across a ton of different securities—which means the capacity of HFT strategies is relatively small.

Good point. Although there are some other areas of trading where speed matters that aren't HFT. An example is the algorithms used to split up large orders into smaller trades in order to hide the position and have a minimum impact on the market price. These are often optimized for very low latency as well. Especially the more sophisticated versions that do things like halt execution in the event that there is news on the stock, etc.

HFT trading is very big.

Maybe not in terms of earnings, but in volume. Estimates range from 30-70%, depending on the market.

I'm digging up references now for an edit...

Volume isn't a particularly relevant metric here. Think of it as the resolution HFT firms trade at rather than a measure of the size of their trading activity. It's not a perfect analogy, but the point is that trade volume is not the best metric for understanding the scope and impact of HFT. It's definitely not an indicator that HFT makes up 30-70% of the finance industry in any meaningful capacity.

Here's a thought experiment: how much would things change if HFT firms traded half as much, with double the margin on each trade? Some securities would be a bit less liquid but otherwise almost nothing would change. It certainly wouldn't be a 2x difference from the status quo!

HFT having a lot of volume is irrelevant, what matters for Julia to be prevalent, is to have a lot of analysts use the toolset. You should measure the amount of analysts working in HFT vs those not working in HFT.

Furthermore - HFT is perhaps the worst case for Julia, since the implementation will always be in low level languages. Julia's speedup is only useful for research in HFT.

Yeah but it's just not really relevant for the vast majority of finance businesses. None of the big banks do HFT for example.

Morgan Stanley and Goldman Sachs might be considered "big banks" and yes, they do.

When raw performance is so important you end up implementing the solution on FPGAs. Switch to Julia does not really matter in such cases.

True. You're pretty much stuck with verilog at that point.

I doubt anyone's currently using Julia for the fast path of low latency trading. Usually it goes from FPGAs for sub-milli work, C++ on GPUs then either C++ or Java for multi-milli work. In my experience.

I'd expect most of the Julia usage in this space would be to replace any R or Matlab in the back testing engines if at all.

I didn't get the impression from the article that they were really talking about low latency anyway.

That's not to suggest that Julia doesn't have a place in Finance. I think it's a great language and there are a bunch of places I can see it being very valuable. Just doubt that low latency fast path is one of them in the near term.

Well, interpreted languages like MATLAB and R can be annoyingly slow at times

Reply on news.ycombinator.com