Question? Leave a message!




Why Java Works (Well) for Low-Latency Trading Systems

Why Java Works (Well) for Low-Latency Trading Systems 5
Why Java Works (Well) for LowLatency Trading Systems Howard Green Azul Systems Inc. 1 1 © 2013 Azul Systems Who we are 2 2 © 2013 Azul Systems Azul Systems: Deep Java DNA • AwardWinning Leader in Java Technology • Founded in 2002, privately held; based in Sunnyvale, CA • Trusted partner to the financial sector for over ten years • Azul CTO Gil Tene on the JCP Executive Committee • Unique technology and IP in Java runtimes and performance ─ Over 40 patents issued, 15 additional filed • Deep lowlatency Java expertise • Strong financial partner ISV ecosystem 3 3 3 3 © 2013 Azul Systems Azul: Proven in Capital Markets Java use cases: • HFT and Algo Trading Platforms • FX, Fixed Income • Realtime Risk • Hedge Funds (CEP) • DMA, Matching Engines, FIX engines, Messaging, BI, more • Lowlatency Java is here – and improving 4 4 © 2013 Azul Systems Java in the low latency world So… Why do people use Java for low latency apps 5 5 5 5 © 2013 Azul Systems Are they crazy 6 6 6 6 © 2013 Azul Systems Are they crazy • No. • There are good, easy to articulate reasons: • Projected lifetime cost • Developer productivity • Timetoproduct, Timetomarket, ... • Leverage, ecosystem, ability to hire 7 7 7 7 © 2013 Azul Systems Why use Java in Algo Trading • One customer’s perspective: “Our strategies have a shelf life” We have to keep developing and deploying new ones Only one out of N is actually productive Profitability therefore depends on ability to successfully deploy new strategies, and on the cost of doing so Our developers seem to be able to produce 2x3x as much when using a Java environment as they would with C/C++ ... 8 8 8 8 © 2013 Azul Systems Some LowLatency Java Examples 9 9 © 2013 Azul Systems FX Example: LMAX Exchange • Londonbased FX exchange • Primarily Open Source infrastructure • 3 ms average latency; 100 Uptime, 500 usec internal latency • LMAX Disruptor: 6 million TPS in 2011 “LMAX Exchange are already the fastest venue for FX and our deep technological collaboration with Azul will help to ensure we continue to deliver even faster execution for our clients in the future." Edward McDaid, CIO, LMAX Exchange 10 10 10 10 © 2013 Azul Systems Algo Example: OptionsCity • JavaBased (Some Scala) ─ Quoting and execution ─ Options pricing and modeling ─ Algo trading ─ Integrated risk management • Colocation next to matching engines at key exchanges • Under 100 µsec round trip 11 11 11 11 © 2013 Azul Systems What’s Driving Java LL Performance 12 12 © 2013 Azul Systems 5 Things People Think They Know about Java 1. Java is inherently slower 2. My team of C and C++ developers can write faster code 3. Java isn't for lowlatency applications 4. Garbage Collection makes Java impractical for Trading 5. Java heap sizes over 10 GB are asking for trouble 13 13 13 13 © 2013 Azul Systems Is Java Slow No • A good programmer will get roughly the same speed from both Java and C++ • A bad programmer won’t get you fast code on either • The 50‘ile and 90‘ile are typically excellent... 14 14 14 14 © 2013 Azul Systems Tiered Compilation • Today’s C1 and C2 compilers generate highquality code • C1: “Fast and Dumb” – 5X10X interpreter speed ─ Smaller code ─ Lowerquality • C2: Slower and Smarter – 3050 faster than C1 ─ Bigger (aggressive/ more inlining) ─ Much higher peak throughput • Tiered (default) behavior – Both are used ─ C1 for fast startup ─ C2 for peak performance • Ensure sufficient iterations for optimization 15 15 15 15 © 2013 Azul Systems Memory Management • Garbage Collectors are getting better • CMS can be very good in tuned applications • Some Jrockit features being added to Oracle HotSpot • Traditional GC target peaks in low milliseconds • Object allocation much faster than malloc • Can drive peak latencies far lower • With aggressive JVM tuning and optimized application • Tens of microseconds peak latency is the rough current state of the industry 16 16 16 16 © 2013 Azul Systems Thread handling • Concurrency has been key to Java since its inception • Moore’s law / human capabilities • Accelerates developer productivity • Asynchronous development simplified • Very fast, low overhead • Originally depended upon operating system • Major advantage of Java – the JVM does more 17 17 17 17 © 2013 Azul Systems “Mechanical Sympathy” • cf: Martin Thompson’s blog • Modern Intelarchitecture servers have lots of cores • …And very good cache designs • Cache miss – “lost opportunity for 500 instructions” • Linux optimizations can help tremendously • Power management can generate more jitter than GC does • Designers that understand how to keep key data in cache… • Locking threads to particular sockets (or cores) • Designing for few (1) writers and many readers 18 18 18 18 © 2013 Azul Systems Better Open Source/ More Profiling Tools • Use of Open Source throughout the financial sector has become widespread • Driven by replatforming onto Linux • Good frameworks and other OSS initiatives help jumpstart development • Java profiling tools are extremely robust ─ AppDynamics ─ New Relic ─ Jprofiler ─ VisualVM ─ Many, many more 19 19 19 19 © 2013 Azul Systems Human Capital is Key • There’s a worldwide war for talent • “The New Kingmakers” – James Governor of RedMonk • You need to provide the best tools and most interesting challenges for your developers • And you’d rather use your best and most creative people to build new functionality and enable new offerings, instead of tuning glitchy legacy systems • Java helps keep your best people engaged in building your business 20 20 20 20 © 2013 Azul Systems Any issues for Java in Trading Systems 21 21 © 2013 Azul Systems Java in Today’s Electronic Markets • Example: some Javabased systems look like this: Traditional JVM: Typical case is fine; worst case more than 20x too high 22 22 22 22 © 2013 Azul Systems Is “jitter” even the right word for this Max is 30,000 higher than “typical” 99‘ile is 60 µsec 23 23 23 23 © 2013 Azul Systems What do actual LL developers do • Today… • They use “Java” instead of Java • They write “in the Java syntax” • They avoid allocation as much as possible • E.g. They build their own object pools for everything • They write all the code they use (no 3rd party libs) • They train developers for their local discipline • In short: They revert to many of the practices that hurt productivity. They lose out on much of Java. 24 24 24 24 © 2013 Azul Systems Summing Up… And a very brief commercial 25 25 © 2013 Azul Systems Realworld Java Performance Low latency trading application 26 26 26 26 © 2013 Azul Systems Standard JVM Zing JVM (pure newgen) Sidebyside – Unmodified Low latency App Drawn to scale… 27 27 27 27 © 2013 Azul Systems Java for Today’s Trading Systems The Zing JVM eliminates the SLA issues and performance glitches people spend weeks (or even months) trying to solve Zing delivers lower averages, eliminates latency spikes 3050 sec peaks in highly tuned applications 28 28 28 28 © 2013 Azul Systems • In one slide… Real Java is finally viable for lowlatency applications Garbage Collection is no longer a dominant issue …Even for outliers No need to code in special ways any more You can finally use “real” Java for everything You can finally 3rd party libraries without worries You can finally use as much memory as you want You can finally use regular (good) programmers 29 29 29 29 © 2013 Azul Systems For more information: Azulsystems.com/solutions/onWallSt Azulsystems.com/solutions/lowlatency Azulsystems.com/solutions/bigdata www.azulsystems.com/resources LinkedIn: /company/azulsystems Twitter: azulsystems FaceBook: AzulSystemsInc Email: hgreenazulsystems.com Phone: +1 650 230 6616 Got Questions Just Ask Us 30 ©2013 Azul Systems, Inc. Everybody knows Java tuning can be tough java Xmx12g XX:MaxPermSize=64M XX:PermSize=32M XX:MaxNewSize=2g XX:NewSize=1g XX:SurvivorRatio=128 XX:+UseParNewGC XX:+UseConcMarkSweepGC XX:MaxTenuringThreshold=0 XX:CMSInitiatingOccupancyFraction=60 XX:+CMSParallelRemarkEnabled XX:+UseCMSInitiatingOccupancyOnly XX:ParallelGCThreads=12 XX:LargePageSizeInBytes=256m java –Xms8g –Xmx8g –Xmn2g XX:PermSize=64M XX:MaxPermSize=256M XX:OmitStackTraceInFastThrow XX:SurvivorRatio=2 XX:UseAdaptiveSizePolicy XX:+UseConcMarkSweepGC XX:+CMSConcurrentMTEnabled XX:+CMSParallelRemarkEnabled XX:+CMSParallelSurvivorRemarkEnabled XX:CMSMaxAbortablePrecleanTime=10000 XX:+UseCMSInitiatingOccupancyOnly XX:CMSInitiatingOccupancyFraction=63 XX:+UseParNewGC –Xnoclassgc Two realworld Java tuning settings. And they contradict each other. 31 31 31 31 © 2013 Azul Systems …Except with Zing java –Xmx40g Just pick a good starting point and let Zing tune itself Now you can focus more on new capabilities And keep your best talent developing instead of tuning 32 32 32 32 © 2013 Azul Systems
Website URL
Comment