<story><title>A JVM Does That? (2011) [pdf]</title><url>http://www.azulsystems.com/blog/wp-content/uploads/2011/03/2011_WhatDoesJVMDo.pdf</url></story><parent_chain><item><author>azeirah</author><text>If performance is THAT critical in HFT, why do they pick java as the starting language?&lt;p&gt;I understand that java is very fast, faster than most people believe, but does it beat hand-optimized assembly? Fortran? C?&lt;p&gt;Why Java?</text></item><item><author>chollida1</author><text>If you are part of the HFT crowd who uses the JVM then you know who the author, Cliff Click, is.&lt;p&gt;His Blogs (former and current) are goldmines for high performance JVM information.&lt;p&gt;&lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;www.azulsystems.com&amp;#x2F;blog&amp;#x2F;author&amp;#x2F;cliff&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;www.azulsystems.com&amp;#x2F;blog&amp;#x2F;author&amp;#x2F;cliff&lt;/a&gt;&lt;p&gt;&lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;www.cliffc.org&amp;#x2F;blog&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;www.cliffc.org&amp;#x2F;blog&amp;#x2F;&lt;/a&gt;&lt;p&gt;I had one CTO of a public HFT firm tell me that short of FPGA&amp;#x27;s Azul&amp;#x27;s pause-less GC (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.azul.com&amp;#x2F;products&amp;#x2F;zing&amp;#x2F;pgc&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.azul.com&amp;#x2F;products&amp;#x2F;zing&amp;#x2F;pgc&amp;#x2F;&lt;/a&gt;) was the biggest performance win they&amp;#x27;d had in the past few years, note: this was a few years ago.&lt;p&gt;EDIT:  someone emailed asking for how HFT firms write their java code.  I haven&amp;#x27;t written java in 3 years so I&amp;#x27;m probably not the best person to author a list but this is what I&amp;#x27;d include:&lt;p&gt;In order of importance:&lt;p&gt;- Measure, measure, measure.  Every HFT firm can tell you to the nanosecond, as much as that&amp;#x27;s possible, what their time is from receiving a packet to when it&amp;#x27;s replied to.  Focus as much, if not more on the 95%, 99% times as the average time.&lt;p&gt;This time increasing is considered a bug in the same way that an app crashing due to user input is considered a bug, which is to say that you just don&amp;#x27;t ship with this kind of bug.&lt;p&gt;- no GC&amp;#x27;s, everything else starts to become less important if the GC is called every 30 seconds.  Some guys will have only one GC call a day, which means you have a really large Eden GC space&lt;p&gt;- short call stacks, and no recursion&lt;p&gt;- one physical core per thread&lt;p&gt;- non locking data structures and use the one writer principle where possible&lt;p&gt;- don&amp;#x27;t use the kernel if possible, ie solar flare Ethernet cards that have userland drivers&lt;p&gt;- cache friendly data structures&lt;p&gt;Watch this video:
&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=iINk7x44MmM&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=iINk7x44MmM&lt;/a&gt;</text></item></parent_chain><comment><author>mavelikara</author><text>Here are my impressions from having worked as a programer on an HFT system during 2009-2011.&lt;p&gt;When an HFT system makes money, some other person or system is loosing money i.e. it is a zero-sum game. And that person isn&amp;#x27;t going to sit idle; they are going to analyze their mistake and up their game. The industry parlance for this is, I think, that the &amp;quot;strategy dissipates into the market&amp;quot;. This causes HFT systems to be always in active development.&lt;p&gt;Spotting a strategy and putting together a system to take advantage of it, and spotting where your system is losing money and fixing it - both these need to be done with quick turn around time.&lt;p&gt;Most strategies can be thought of as picking up nickels from in front of a on-coming train. Your best case &amp;quot;win&amp;quot; is a tiny amount of money; but your worst case &amp;quot;loss&amp;quot; is much much more money. The trick in HFT - the HF part - is to make these tiny wins over and over. But much actual money is involved, with very bad consequences should the program run into inopportune bugs.&lt;p&gt;All of these - constant development, time to market pressure, high reliability - give the impression that Java is a better language to code this HFT systems in than C or Fortran.</text></comment>
<story><title>A JVM Does That? (2011) [pdf]</title><url>http://www.azulsystems.com/blog/wp-content/uploads/2011/03/2011_WhatDoesJVMDo.pdf</url></story><parent_chain><item><author>azeirah</author><text>If performance is THAT critical in HFT, why do they pick java as the starting language?&lt;p&gt;I understand that java is very fast, faster than most people believe, but does it beat hand-optimized assembly? Fortran? C?&lt;p&gt;Why Java?</text></item><item><author>chollida1</author><text>If you are part of the HFT crowd who uses the JVM then you know who the author, Cliff Click, is.&lt;p&gt;His Blogs (former and current) are goldmines for high performance JVM information.&lt;p&gt;&lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;www.azulsystems.com&amp;#x2F;blog&amp;#x2F;author&amp;#x2F;cliff&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;www.azulsystems.com&amp;#x2F;blog&amp;#x2F;author&amp;#x2F;cliff&lt;/a&gt;&lt;p&gt;&lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;www.cliffc.org&amp;#x2F;blog&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;www.cliffc.org&amp;#x2F;blog&amp;#x2F;&lt;/a&gt;&lt;p&gt;I had one CTO of a public HFT firm tell me that short of FPGA&amp;#x27;s Azul&amp;#x27;s pause-less GC (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.azul.com&amp;#x2F;products&amp;#x2F;zing&amp;#x2F;pgc&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.azul.com&amp;#x2F;products&amp;#x2F;zing&amp;#x2F;pgc&amp;#x2F;&lt;/a&gt;) was the biggest performance win they&amp;#x27;d had in the past few years, note: this was a few years ago.&lt;p&gt;EDIT:  someone emailed asking for how HFT firms write their java code.  I haven&amp;#x27;t written java in 3 years so I&amp;#x27;m probably not the best person to author a list but this is what I&amp;#x27;d include:&lt;p&gt;In order of importance:&lt;p&gt;- Measure, measure, measure.  Every HFT firm can tell you to the nanosecond, as much as that&amp;#x27;s possible, what their time is from receiving a packet to when it&amp;#x27;s replied to.  Focus as much, if not more on the 95%, 99% times as the average time.&lt;p&gt;This time increasing is considered a bug in the same way that an app crashing due to user input is considered a bug, which is to say that you just don&amp;#x27;t ship with this kind of bug.&lt;p&gt;- no GC&amp;#x27;s, everything else starts to become less important if the GC is called every 30 seconds.  Some guys will have only one GC call a day, which means you have a really large Eden GC space&lt;p&gt;- short call stacks, and no recursion&lt;p&gt;- one physical core per thread&lt;p&gt;- non locking data structures and use the one writer principle where possible&lt;p&gt;- don&amp;#x27;t use the kernel if possible, ie solar flare Ethernet cards that have userland drivers&lt;p&gt;- cache friendly data structures&lt;p&gt;Watch this video:
&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=iINk7x44MmM&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=iINk7x44MmM&lt;/a&gt;</text></item></parent_chain><comment><author>sandisk5</author><text>Because performance isn&amp;#x27;t the only requirement and Java is fast enough.&lt;p&gt;Correctness, maintenance, extensibility, developer productivity, tooling, deployment, and recruiting are all also important.</text></comment>