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

We chose Java for our high-frequency trading application

medium.com

Post reply on HN
Print view View original

201–210 of 287 posts

Re: We chose Java for our high-frequency trading application

#201

Post by mschuster91 »

cwt137 wrote: post #141

I don't like how the author of the article said that PHP is an interpreted language and thus does not execute anything like Java is executed. I'm not saying PHP executes just like Java, but PHP is more like Java than he realizes. PHP does not execute line by line like an interpreted language. But takes the source and compiles it down to an intermediate representation (IR), just like Java. Java calls it bytecode, PHP…

The key difference between Java and PHP is the lack of a compilation step. I can change a line of code, press cmd+r and I see the change - whereas in Java more often than not I have to wholly restart the application container as hot-reloading is a complicated mess and tough to set up.

Also, in Java it is easy to end up with resource leaks whereas PHP always starts from a clean slate for each request. Way less headache for operations.

Re: We chose Java for our high-frequency trading application

#202

Post by paulpauper »

immmmmm wrote: post #63

I have a question: When i finished my theoretical Physics PhD, HFT was THE way out of academia for making money in my field. I didn't follow this path as it felt at the time a pretty evil thing to do. Does HFT provide any benefits for our society?

what aspect of theoretical physics did you get your phd in?

Re: We chose Java for our high-frequency trading application

#203

Post by whizzter »

jacques_chester wrote: post #158
Androider wrote: post #131

Earlier quoted context omitted.

1TB of RAM is cheap though, versus spending engineering hours. Reminds me of the classic WTF "That would've been an option too" https://thedailywtf.com/articles/That-Wouldve-Been-an-Option...

> 1TB of RAM is cheap though, versus spending engineering hours. It's not about the amount of RAM, it's how fast and predictable the overall system is. Note in particular the remark about cache locality; that can be the difference between nanoseconds and microseconds.

What the GP is referring to (Misc.Unsafe) is basically going back to manual pointer reads/writes (IE writing more or less C code in Java), the benefit is you get C speed/memory layout/cache-locality but with the downside of writing it in a less suited language (Java).

HOWEVER If you DO _allocate_ much then 1TB seems like a great choice since GC pauses are killers w.r.t. latency in comparison to cache issues. A cache line (often 64 bytes) would probably only hold at most a couple of Java objects (minimum is probably like 16 or more bytes for each small object) so cache locality won't be improved much by a GC (Yes, the G1 GC in newer JDK's does neighbour compacting iirc so you get a little cache locality but only if the patterns were bad from the start, but avoiding GC entirely is better)

Re: We chose Java for our high-frequency trading application

#204

Post by koheripbal »

mschuster91 wrote: post #201
cwt137 wrote: post #141

I don't like how the author of the article said that PHP is an interpreted language and thus does not execute anything like Java is executed. I'm not saying PHP executes just like Java, but PHP is more like Java than he realizes. PHP does not execute line by line like an interpreted language. But takes the source and compiles it down to an intermediate representation (IR), just like Java. Java calls it bytecode, PHP…

The key difference between Java and PHP is the lack of a compilation step. I can change a line of code, press cmd+r and I see the change - whereas in Java more often than not I have to wholly restart the application container as hot-reloading is a complicated mess and tough to set up. Also, in Java it is easy to end up with resource leaks whereas PHP always starts from a clean slate for each request. Way less headach…

Right, but in a corporate production environment where everything is probably deployed compiled or compiled shortly after, does that matter? No one is altering prod code.

Re: We chose Java for our high-frequency trading application

#205

Post by darawk »

immmmmm wrote: post #63

I have a question: When i finished my theoretical Physics PhD, HFT was THE way out of academia for making money in my field. I didn't follow this path as it felt at the time a pretty evil thing to do. Does HFT provide any benefits for our society?

Yes, HFT provides liquidity to capital markets, reducing transaction costs of financing. The social benefits here can be a bit hard to see, but they are certainly real. When HFTs make money, it's because they're buying low and selling high. That means that they are making prices slightly more efficient for the next person to come along, which in turn means that that next person gets a slightly better more accurate price.

Re: We chose Java for our high-frequency trading application

#206

Post by smabie »

offtop5 wrote: post #200
smabie wrote: post #193

Earlier quoted context omitted.

I work in HFT and base comp is pretty much irrelevant. In fact at the firm I work at, every single employee gets the same base salary (low 6 figures). Not that's not important: everyone makes way more money through their part of profits depending on their equity and their amount invested in the fund. Total cash compensation easily gets above 400-500k. People probably make less money at large firms, tho.

Thanks for the tip ! . I'm eyeing an early retirement, so I'd like to live off 100k and save the rest. Would you consider your job high stress ?

It's stressful in the sense that the amount you earn is a linear function on the performance of the strategy. Unlike at other firms, bonus isn't discretionary: its a pure function of strategy performance. When the company loses money, you lose money. This incentivizes everyone to work together and solve problems.

Also working with some of the smartest people in the industry can be intimidating: if you're used to being the smartest guy in the room, it's very unlikely you will be anymore at a top notch firm. This is a form of stress in itself.

It's not stressful in the sense of shitty clueless bosses, long unpaid hours (people work long hours, but that work is often highly compensated for through pnl improvements).

Everyone I know feels extremely lucky that by just putting our heads together, we can mint money out of thin air. I don't think anyone I work with would rather be doing anything else. Trying to make money out of nothing certainly humbles you, but when something works, its the best feeling in the world.

Keep in mind that things might be different at a larger firm: lower compensation and upside, more hierarchy, etc.

Re: We chose Java for our high-frequency trading application

#207

Post by pizlonator »

Very cool to see Java continue to be used in high perf situations.

Something about warmup: this is an area where JVMs still have catching up to do versus JavaScript VMs. JVMs have suboptimal startup time in the non-cached case (I.e. not what they are doing with Zing) because it’s just not been an optimization target for JVM hackers. In the JSVM world, we were forced to optimize for this and optimize we did (otherwise page loads would suck). I suspect that Zing with the ReadyNow thing is way better than normal Java, but I don’t know if it’s better than what JSVMs do. It’s probably still way worse if you’re not cached. It might be better in the cached case but then again JSVMs also save some profiling in the cache (JSC definitely does). That suggests that JVMs can probably improve further. No reason why Java - an overall very performant language - should start slower when uncached than JS. I suspect this will get fixed since AOT is a thing now, but getting start times right is about way more than just JITing less.

Re: We chose Java for our high-frequency trading application

#208

Post by slotrans »

usefulcat wrote: post #92

"An improvement can be discussed in the morning, and be implemented, tested and released in production in the afternoon." I feel like they've buried the lead here. If the above statement is really as it sounds, I find that way more impressive than the fact that they were able to make java fast.

This is just normal software development.

If you avoid overloading yourself with unnecessary complexity, and you as an engineer spend time understanding the problem/business domain, there's no reason why this speed of turnaround should be unattainable.

I have frequently had the experience of sitting in a meeting with (internal) customers and/or a product manager, and shipping discussed changes during that meeting.

If you can't do this, it's because you've put barriers in your own way. Ask yourself if they're really worth it. (They might be!)

Re: We chose Java for our high-frequency trading application

#209

Post by offtop5 »

smabie wrote: post #206
offtop5 wrote: post #200

Earlier quoted context omitted.

Thanks for the tip ! . I'm eyeing an early retirement, so I'd like to live off 100k and save the rest. Would you consider your job high stress ?

It's stressful in the sense that the amount you earn is a linear function on the performance of the strategy. Unlike at other firms, bonus isn't discretionary: its a pure function of strategy performance. When the company loses money, you lose money. This incentivizes everyone to work together and solve problems. Also working with some of the smartest people in the industry can be intimidating: if you're used to bein…

So for my last question, did you have to know someone to get into this field. I'm in fintech right now, and I'm well compensated, I love my job but if I can reach the Pinnacle programming, IE pulling 400 or 500k a year. That would be simply awesome.

Would it be easier to target bigger firms and then get into or start my own firm ?

Re: We chose Java for our high-frequency trading application

#210

Post by mindentropy »

oppositelock wrote: post #74
cashewchoo wrote: post #5

I think I actually saw these folks present at JavaOne a couple years ago? Either that or there's more than one shop branding itself as "HFT" that uses Java. I worked in the industry and it's always a little funny to see who calls themselves HFTs vs quants. Basically, there's a bit of a spectrum of fast vs smart. In general it's hard to do incredibly smart stuff fast enough to compete in the "speed-critical" bucket of…

I discovered something amazing when working with some people who were writing HFT software. Why do you need 1TB of RAM in these machines? Because when you're Java based, you want to avoid stop-the-world GC pauses. These trading systems only have to be up from 9:30AM-4:30PM EST, so they simply disable GC altogether! At the end of a trading day, restart the app or reboot the system.

Why don't they use fixed size arrays like in embedded systems and not allocate memory dynamically?
Post reply on HN