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 calls it OPCodes. Also like Java, PHP then takes that IR and executes it on a VM. Java's is stack based and PHP is register based, if I remember correctly. Many PHP accelerators / caching solutions save the IR and thus, the next time the code is needed, no compilation of source code is done.
We chose Java for our high-frequency trading application
141–150 of 287 posts
Re: We chose Java for our high-frequency trading application
#142I had to laugh at one line. PHP or Perl are called interpreted because the interpreter (installed on the destination machine) compiles each line of code as it goes. Yeah, that hasn't been true of most "interpreted languages" in decades. The most common interpreted languages that I can think of where you parse as you go are shells like bash. Languages like Perl and PHP are called interpreted because an interpreter run…
if you've got a script the likes of:
#!/bin/bash
echo 'Hi!'
sleep 20
echo 'Hello!'
... and runt it... and while the script is executing the sleep line, modify it so that instead of 'echo "Hello!"' it does something else, like 'echo "Oops!"'...
... once it resumes from the sleep, it'll execute the updated code.
Don't ask me how I know... I just wish it were more well-known.
Don't modify shell scripts while they're running!
Re: We chose Java for our high-frequency trading application
#143Earlier quoted context omitted.
If you want something that's as fast as C++, but safer to work with, then there's this new language, has been on HN frontpage once or twice.. I can't remember the name, but I think it had something to do with oxidation of metals.. Something about shellfish as well..
The person you're replying to is almost certainly not using the word "safe" in the same sense you are. In particular: safety in trading has to do with risk management, strategy correlation, side effects, and correctness. Software security matters, in the abstract, but trading firms don't care about it nearly as much as tech companies do. The other thing is that being as fast as C++ is not compelling enough a reason t…
Re: We chose Java for our high-frequency trading application
#144Earlier quoted context omitted.
Some people argue that HFT provides liquidity for retail investors, but it's debatable whether that liquidity is real or not since it'll be gone during black swan events. At the same time HFT profit from uninformed/retail flow. So it's debatable wether the actual activity provides values. I'd say probably not. But there can be indirect value in working in HFT, just like there is with other demanding jobs. There's int…
I think that's getting a little high minded for the purpose of the OP's question. I think it's fair to interpret the question as "Is there a good faith argument that HFT is beneficial to markets in a way that also benefits everyday citizens? Are there positive downstream effects? Is the intent of HFT strictly selfish?" I don't think your comparison to academia holds up there.
Re: We chose Java for our high-frequency trading application
#145I had to laugh at one line. PHP or Perl are called interpreted because the interpreter (installed on the destination machine) compiles each line of code as it goes. Yeah, that hasn't been true of most "interpreted languages" in decades. The most common interpreted languages that I can think of where you parse as you go are shells like bash. Languages like Perl and PHP are called interpreted because an interpreter run…
Re: We chose Java for our high-frequency trading application
#146I 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.
Over a decade ago, we used a third-party pre-trade risk system that was implemented in Java. Since it was a "service" (we connected to a TCP port), the underlying tricks they used to make it "fast" were transparent to us... until it was not.
They highly tuned their GC to where there was seldom any GC. One day, the third-party made a change to a supervisory service to generate more periodic monitoring emails. The file handles from this actor were apparently not GC'd and held by the process until the system ran out of file handles. That made the service stop working properly.
But, in addition to alerting, that service had a more important job: it was a post-trade risk "watchdog" to the pre-trade risk gateways, which we sharded across.
The various pre-trade risk gateways, upon not hearing from the watchdog authority then 1) began cancelling outstanding orders and 2) not allow new orders. We saw this happening haphazardly over 10 minutes and had little time and capability to recover; this also happened near the end of the trading day when some orders (MOC, LOC) are not cancellable. This was across our whole organization so it affected many strategies. So it wasn't as simple as "stop all" and although we had many checks and recovery procedures, this was a pretty special Chaos Monkey.
We ended up with a >$1B basket of random stocks that cost >$10M to liquidate over the next few days.
$10M evaporating in 10 minutes because of "GC optimizations" and poorly considered OS settings.
The #1 risk in algo/HFT trading is not financial, but operational.
[Some of the technical details may be slightly off, as it was third-party; my outlook is pieced together from post-mortems. Also, no other party (e.g. broker, SIPC, market participant, the third-party) was financially affected besides our firm.]
Re: We chose Java for our high-frequency trading application
#147Earlier quoted context omitted.
Better or worse than Ad tech based companies? Most traders I've met have been fairly honest about contributing nothing to society, or that the world would probably be a better place is large segments of the finance industry disappeared tomorrow. I can't say the same for the majority of developers from Facebook or Google I've met.
??? I run ads and campaigns for my company and they are an absolutely essential form of communication. ... as almost everyone running and actual business knows. Yes - it can be very inefficient - but it's not inherently wasteful. You're making the wrong comparison - the 'Digital Ad Industry' could be compared to 'Digital Banking Industry' perhaps - i.e. useful overall but deficiencies exist. HFT is one of the ares in…
For your company, not for the World.
Re: We chose Java for our high-frequency trading application
#148Re: We chose Java for our high-frequency trading application
#149Earlier quoted context omitted.
Speaking from experience with JVM HFT applications (we used Scala). There are a lot of tricks though to not require 1TB. And allocation in general is a bad idea even if you don't collect because it scatters stuff all over memory and messes up cache locality. You really, really don't want to allocate in a performance sensitive jvm application if you can avoid it. It's the opposite of a lot of what I was told and taugh…
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...
Re: We chose Java for our high-frequency trading application
#150I 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…