Azul for HFT

[Janny]

Just curios are there any examples of Azul usage in HFT? I have never heard that the biggest banks use it. Also what is the future of investment with value types coming in the future JDK versions?

[Martin Thompson]

Most of the biggest banks in capital markets and quite a few trading companies use Azul Zing. Many are just not that open about their technology stack.

On 18 February 2015 at 01:43, Janny <winnie...@gmail.com> wrote:

Just curios are there any examples of Azul usage in HFT? I have never heard that the biggest banks use it. Also what is the future of investment with value types coming in the future JDK versions?

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Janny]

Hi Martin, 

Do you have facts that most of the biggest banks in Capital Markets use Azul Zing? Especially I'm sceptical about the word most. I can believe in a few (as a guys from this world), but also I can't find any azul/zing job among 9920 investment banking jobs worldwide (http://www.efinancialcareers.com/search?keywords=Zing%2Cazul). 

I can give more serious facts also.

Thanks.

On Wednesday, February 18, 2015 at 4:39:05 PM UTC+8, Martin Thompson wrote:

Most of the biggest banks in capital markets and quite a few trading companies use Azul Zing. Many are just not that open about their technology stack.

On 18 February 2015 at 01:43, Janny <winnie...@gmail.com> wrote:

Just curios are there any examples of Azul usage in HFT? I have never heard that the biggest banks use it. Also what is the future of investment with value types coming in the future JDK versions?

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

[Martin Thompson]

I cannot give more details because as I said before financial organisations are often, unnecessarily, secretive about such things. Like all good science you should not take what I say for any more than the evidence that is provided. The only thing you can read into it is that I do not work for Azul and it benefits me in no way offering this. I know Gil because we often end up helping the same clients.

Regarding the jobs search. In my experience you develop plain old Java for Zing and it requires almost no special tuning for use in low-latency. It does much better with idiomatic OO than other JVMs. This is not that case with Hotspot which requires very specialised skills to tune and develop for in a low-latency environment. Also consider that the biggest banks are also very big. This means that they will not use the same technology in every department. In my experience it is not uncommon for one department to not know what other departments are doing.

On 18 February 2015 at 10:52, Janny <winnie...@gmail.com> wrote:

Hi Martin, 

Do you have facts that most of the biggest banks in Capital Markets use Azul Zing? Especially I'm sceptical about the word most. I can believe in a few, but also I can't find any azul/zin job among 9920 investment banking jobs worldwide (http://www.efinancialcareers.com/search?keywords=Zing%2Cazul). 

I can throw more serious facts also.

Thanks.

On Wednesday, February 18, 2015 at 4:39:05 PM UTC+8, Martin Thompson wrote:

Most of the biggest banks in capital markets and quite a few trading companies use Azul Zing. Many are just not that open about their technology stack.

On 18 February 2015 at 01:43, Janny <winnie...@gmail.com> wrote:

Just curios are there any examples of Azul usage in HFT? I have never heard that the biggest banks use it. Also what is the future of investment with value types coming in the future JDK versions?

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Jean-Philippe BEMPEL]

On Wednesday, February 18, 2015 at 12:10:04 PM UTC+1, Martin Thompson wrote:

 Also consider that the biggest banks are also very big. This means that they will not use the same technology in every department. In my experience it is not uncommon for one department to not know what other departments are doing.

+1000 on this statement, This is without doubt the reason of this discrepancy :) 

[Jan van Oort]

Coincides 100% with my experience with large insurers and banks. One department may have been using X with great success, with another department struggling to choose between Y and Z. 

Fortuna audaces adiuvat - hos solos ? 

--

[Janny]

"+1000" here and there makes me feel better about my job security. ;-)

[Janny]

This is all good in theory, but in practice if a good number of banks uses Zing, why I have never heard about it?

Someone from my friends who work in other banks or hedge funds would definitely mention it. I went through many interviews with big banks for equities and FX trading in the past, but have never heard a world about Zing. Here where I live all these hedge funds and big banks don't afraid to mention about fpga, C++, STL or just core java, kdb+ for HFT roles - but they don't mention Zing in the job descriptions. I know what kind of projects we have in our company and what kind of technologies we use. Nobody will be using Zing, for example, for fixed income trading, usually for Equities and FX (the usage is quite narrow, so not so many departments in the banks who potentially may use it). I'm very very sceptical...

On Wednesday, February 18, 2015 at 9:47:55 PM UTC+8, Jan van Oort wrote:

Coincides 100% with my experience with large insurers and banks. One department may have been using X with great success, with another department struggling to choose between Y and Z. 

Fortuna audaces adiuvat - hos solos ? 

On 18 February 2015 at 14:20, Jean-Philippe BEMPEL <jpbe...@gmail.com> wrote:

On Wednesday, February 18, 2015 at 12:10:04 PM UTC+1, Martin Thompson wrote:

 Also consider that the biggest banks are also very big. This means that they will not use the same technology in every department. In my experience it is not uncommon for one department to not know what other departments are doing.

+1000 on this statement, This is without doubt the reason of this discrepancy :) 

--

You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

[Vitaly Davidovich]

FWIW, I worked in a big bank for a while and also never heard of any group using Azul.  I believe it was evaluated at some point, but was not picked (don't know the reasons).  That's not to say I don't believe it's used in banks, but I've also not heard of it much from other folks I know who work in big financial corps.

I do know that the groups using java for low latency are particularly careful about the way they write code.  In a nutshell, it consists of avoiding allocations in hot paths and sizing eden such that you make it through the day without any GC.

sent from my phone

On Feb 18, 2015 9:08 AM, "Janny" <winnie...@gmail.com> wrote:

This is all good in theory, but in practice if a good number of banks uses Zing, why I have never heard about it?

Someone from my friends who work in other banks or hedge funds would definitely mention it. I went through many interviews with big banks for equities and FX trading in the past, but have never heard a world about Zing. Here where I live all these hedge funds and big banks don't afraid to mention about fpga, C++, STL or just core java, kdb+ for HFT roles - but they don't mention Zing in the job descriptions. I know what kind of projects we have in our company and what kind of technologies we use. Nobody will be using Zing, for example, for fixed income trading, usually for Equities and FX (the usage is quite narrow, so not so many departments in the bank may be using it). I'm very very sceptical...

On Wednesday, February 18, 2015 at 9:47:55 PM UTC+8, Jan van Oort wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Janny]

I may probably post the final very bold statement until Gil decide to answer. Big Banks do not care about the latency/throughput  so much as Azul may think they do (they care, but they may all achieve they need with JDK or they have big salary budget and they use C++), and hedge fund usually choose C/C++, because usually scalping is the only source of income - straight from the horse mouth

On Wednesday, February 18, 2015 at 10:22:18 PM UTC+8, Vitaly Davidovich wrote:

FWIW, I worked in a big bank for a while and also never heard of any group using Azul.  I believe it was evaluated at some point, but was not picked (don't know the reasons).  That's not to say I don't believe it's used in banks, but I've also not heard of it much from other folks I know who work in big financial corps.

I do know that the groups using java for low latency are particularly careful about the way they write code.  In a nutshell, it consists of avoiding allocations in hot paths and sizing eden such that you make it through the day without any GC.

sent from my phone

On Feb 18, 2015 9:08 AM, "Janny" <winnie...@gmail.com> wrote:

This is all good in theory, but in practice if a good number of banks uses Zing, why I have never heard about it?

Someone from my friends who work in other banks or hedge funds would definitely mention it. I went through many interviews with big banks for equities and FX trading in the past, but have never heard a world about Zing. Here where I live all these hedge funds and big banks don't afraid to mention about fpga, C++, STL or just core java, kdb+ for HFT roles - but they don't mention Zing in the job descriptions. I know what kind of projects we have in our company and what kind of technologies we use. Nobody will be using Zing, for example, for fixed income trading, usually for Equities and FX (the usage is quite narrow, so not so many departments in the bank may be using it). I'm very very sceptical...

On Wednesday, February 18, 2015 at 9:47:55 PM UTC+8, Jan van Oort wrote:

Coincides 100% with my experience with large insurers and banks. One department may have been using X with great success, with another department struggling to choose between Y and Z. 

Fortuna audaces adiuvat - hos solos ? 

On 18 February 2015 at 14:20, Jean-Philippe BEMPEL <jpbe...@gmail.com> wrote:

On Wednesday, February 18, 2015 at 12:10:04 PM UTC+1, Martin Thompson wrote:

 Also consider that the biggest banks are also very big. This means that they will not use the same technology in every department. In my experience it is not uncommon for one department to not know what other departments are doing.

+1000 on this statement, This is without doubt the reason of this discrepancy :) 

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscribe...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Vitaly Davidovich]

I wouldn't be that bold :).  "Big banks" is too broad; it's definitely the case that groups within these banks are oft not aware of what others are doing (just like most large organizations), I agree with that observation.  It's also the case that only certain groups would require that type of latency SLA crucial to their business, so certain divisions simply don't need this at all.

There are definitely low latency players using java, but keep in mind that it also doesn't have to be black and white: you can mix java with native code where it makes sense.

sent from my phone

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.

[Jean-Philippe BEMPEL]

I think financial industry is pretty large even vast. From my views I do not agree with your statement, but I doubt I have an exhaustive view of what it is used in the whole sector.

In my company we have big banks as customers, we are doing low latency, low & high throughput and we are using Zing (but not only!).

Saying all Big Banks are knowing about Zing or using it, I am not in a position to affirm it, but I have experiences and examples.

[Martin Thompson]

You seem to be posting statements and disagreeing with others who are simply offering their viewpoint. We all have a limited sample set and all we can do is share what we know.

What are you looking to discover with the question? Do you have a need at work for which you need to know some technical answer?

[Janny]

it is okay to disagree with facts. tried to understand who may use Zing and hear about experience vs optimized JDK, also I asked a question about future as java will be soon moving to off-heap structures - just have interest to hear what people in low latency field may think about it and where else Zing may be better.

[Vitaly Davidovich]

What do you mean by java moving to offheap structures? Value types? If so, that in no way will displace Azul.

sent from my phone

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.

[Martin Thompson]

Well it looks like some peoples sample set have observed Zing being used in banks and trading firms. For others they have not. You then jumping to the conclusion that Gil is wrong about latency needs is not good analysis of the facts given the responses. Would you call that good analysis?

Regarding your other question about value types. Value types are very much an on-heap construct and not off-heap as you seem to think. Due to the ability to stack allocate them we should see benefits from locality of reference and less GC pressure. However we would not have guarantees for the locality of reference. I'd expect more benefits to throughput rather than predictable latency without applying a deep understanding of how the JVM will implement them.

[Vitaly Davidovich]

While it does remain to be seen how they're implemented, unless it's completely botched (which I doubt), I do expect it to improve throughput *and* latency in *some* cases (assuming code is updated to use value types where applicable).  It should also facilitate writing cleaner code without sacrificing performance.  That's certainly been the case with .NET's structs (for a slight flavor of that: http://samsaffron.com/archive/2011/10/28/in-managed-code-we-trust-our-recent-battles-with-the-net-garbage-collector).

Ultimately, if done right, they should come with similar performance gains to using primitives over custom value classes today.

--

You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.

[Martin Thompson]

Yes they should be a good thing for the language when they arrive. We could kill off the horrid Pair<V1, V2> style classes to deal with returning more than one thing as an example :-)

On a single thread I would expect a mean reduction in latency when you see an increase in throughput. I guess this is the "some" cases as you carefully highlight. Depending on coding pattern and stack limits they may not always be stack allocated. They also may not be co-located in memory with an aggregate class of which they are a part. That is why I cautioned about "predictable latency" not just low latency.  I'm more interested in the distribution rather than the mean.

I'm fascinated to see how they can be implemented.

[Vitaly Davidovich]

On a single thread, taking GC pressure out of the equation (which of course is a big reason why they could reduce "global" app-level latency), they should act just like if you were using a primitive (assuming the underlying storage is of same size).  There is this whole thing about "we're allowed to heap allocate if the value type is over some size threshold", but I'm assuming that threshold is going to be sufficiently large such that no reasonable/sane value type will hit that limit (this is par of what I meant by "not botching" the implementation).  They will come with copying costs given they're intended to be immutable, whose performance hit will depend on the shape of the value type, but given the alternative (allocating in the heap), I'll take that any day of the week.

They can also reduce overall heap footprint if many instances of value classes are switched over to value types (i.e. lose header bytes on each instance).

In terms of layout control, yeah, there's no guarantee of anything; that's somewhat similar to primitives today, although the layout algorithm used is known and can be played with to varying degree of success.  However, again given the alternative of chasing a pointer, I'll take that any day of the week as well :).

For the (I think) expected common case of a value type with just a few primitives underneath, the scalarizing of that would yield pretty good benefits since data will be placed into registers (assuming no register pressure, but at worst, spilled/reloaded to/from stack) directly.

The two dampers on them are (1) always immutable (there are some cases where that's not ideal) and (2) no way to pass them by-ref (to avoid copying cost for large-ish ones.  Both scenarios are somewhat rare, so shouldn't be too big of a deal.

--

[Jimmy Jia]

Much love to Gil and everyone else, but the truth regarding Zing and HFT is that it depends a lot on what your definition of "low latency" is.

If your issues are around GC pauses caused by object allocation in FIX handling, it's pretty likely that Zing will help you out quite a bit. That's a different level of "low latency" than, say, worrying about shaving off the last µs or two on your critical path. Zing v HotSpot just isn't going to matter there.

It really is bizarre how outside of this community, most discussions of how to tune Java GC pausing don't have a footnote that just says "or go use Zing", though.

On Wed, Feb 18, 2015, 10:48 Martin Thompson <mjp...@gmail.com> wrote:

Yes they should be a good thing for the language when they arrive. We could kill off the horrid Pair<V1, V2> style classes to deal with returning more than one thing as an example :-)

On a single thread I would expect a mean reduction in latency when you see an increase in throughput. I guess this is the "some" cases as you carefully highlight. Depending on coding pattern and stack limits they may not always be stack allocated. They also may not be co-located in memory with an aggregate class of which they are a part. That is why I cautioned about "predictable latency" not just low latency.  I'm more interested in the distribution rather than the mean.

I'm fascinated to see how they can be implemented.

On 18 February 2015 at 15:29, Vitaly Davidovich <vit...@gmail.com> wrote:

While it does remain to be seen how they're implemented, unless it's completely botched (which I doubt), I do expect it to improve throughput *and* latency in *some* cases (assuming code is updated to use value types where applicable).  It should also facilitate writing cleaner code without sacrificing performance.  That's certainly been the case with .NET's structs (for a slight flavor of that: http://samsaffron.com/archive/2011/10/28/in-managed-code-we-trust-our-recent-battles-with-the-net-garbage-collector).

Ultimately, if done right, they should come with similar performance gains to using primitives over custom value classes today.

On Wed, Feb 18, 2015 at 10:09 AM, Martin Thompson <mjp...@gmail.com> wrote:

Regarding your other question about value types. Value types are very much an on-heap construct and not off-heap as you seem to think. Due to the ability to stack allocate them we should see benefits from locality of reference and less GC pressure. However we would not have guarantees for the locality of reference. I'd expect more benefits to throughput rather than predictable latency without applying a deep understanding of how the JVM will implement them.

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

[Jimmy Jia]

The other thing is, for very low latency trading applications, if you are using Java and have been for a while (i.e. before you found out about Zing), you've probably already written all of your code to not generate any garbage at all (or gone out of business). Zing's ReadyNow! looks pretty amazing, but if GC pauses are causing issues for you, you're not really doing HFT.

If you were starting from scratch? Or have a non-HFT application in Java where you want to get rid of pauses? Then Zing looks pretty damn good. Although given the current respective states of C++11/14 v Java, it's true that you might just want to go with C++ unless you like Java a lot better, if you're targeting very low latency for HFT - but you'll still be slower than people who aren't only using software.

Zing is a pretty broadly applicable product rather than a niche one, but there are plenty of vagaries about the shape of the space that mean there are quite large niches where Zing isn't that applicable or helpful, and unfortunately for Zing, a lot of stuff lives in those niches.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscribe...@googlegroups.com.

[Michael Barker]

You could always look at the list of customers on their website:

http://www.azulsystems.com/content/case-studies

There's section for finance, with a number of well known banks.

On 18 February 2015 at 14:43, Janny <winnie...@gmail.com> wrote:

Just curios are there any examples of Azul usage in HFT? I have never heard that the biggest banks use it. Also what is the future of investment with value types coming in the future JDK versions?

--

You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.

[Jan van Oort]

<quote>There's section for finance, with a number of well known banks</quote>

Including LMAX, Peter Lawrey's outfit. Which in and by itself is already quite the reference, I daresay. 

Fortuna audaces adiuvat - hos solos ? 

[Martijn Verburg]

Hi all,

For reference I run jClarity (We provide Censum, the GC analysis tool for Hotspot & some other performance tooling).

We are often called in to assist clients with their Hotspot GC problems around latency (in particular for financial services), if we're unable to tune Hotspot to meet the customers latency requirements then we don't hesitate for a second to recommend Zing. Sometimes that requirement is obviously low/stringent enough that it simply elicits the "Go buy Zing" response from us. There are certain latency requirements that Hotspot collectors are never going to meet consistently (G1 is slowly starting to get push down, but I suspect most people on this list wouldn't consider it a 'low-latency' collector). *Maybe* further G1 improvements and/or Shenandoah will push Hotspot a little further into that space, but there is a lot of work to be done there yet and we don't pretend to customers otherwise.

I'd say that I've personally seen Zing in a couple of the Tier 1's, several of the Tier 2/3's + a bunch of other players in the market. From what I've observed these aren't typically "replace the whole 100,000 JVM plant" type installations, more like strategic ones in areas where latency matters a great deal and the system is written in Java. Again, as Martin points out, I'm just one sample data source here, only Azul's CRM likely knows the truth ;-).

Cheers,
Martijn

[Michael Barker]

Including LMAX, Peter Lawrey's outfit. Which in and by itself is already quite the reference, I daresay. 

It is true that we (LMAX) use Zing, but worth noting that Peter Lawery does not work for us.

[Jan van Oort]

Wasn't he the author of the Disruptor pattern and implementation with you guys ? I always thought so. 

Fortuna audaces adiuvat - hos solos ? 

On 18 February 2015 at 22:32, Michael Barker <mik...@gmail.com> wrote:

Including LMAX, Peter Lawrey's outfit. Which in and by itself is already quite the reference, I daresay. 

It is true that we (LMAX) use Zing, but worth noting that Peter Lawery does not work for us.

--

[Jimmy Jia]

BTW, the counter-point to "LMAX use Zing" is probably "NASDAQ don't use Zing".

What I'm really getting at is - if you want to optimize latency in a Java application where GC pauses are a concern, you probably want to use Zing. If you think through and understand why NASDAQ don't use Zing, then you'll understand why their reasons don't really apply to the scenario I just pointed out, which should probably point you toward using Zing.

[Martin Thompson]

Check the original commit log for the Disruptor :-)

https://code.google.com/p/disruptor/source/browse/#svn%2Ftrunk%2Fcode%2Fsrc

[Jan van Oort]

Point taken, Martin. IOU a beer :-)

Fortuna audaces adiuvat - hos solos ? 

[Martin Thompson]

I was also the co-founder and CTO of LMAX but that is in the past these days.

[Michael Barker]

Peter has done some really interesting work in a similar space.  Checkout https://github.com/OpenHFT.

Mike.

[Martin Thompson]

There is no one true technology for success right now. Last time I looked the top exchanges by volume and their implementation language in the US were in no particular order:

NYSE/NASDAQ - C

ICE - Java

Direct Edge - C#

CME - Java

Bats - C

All keep re-evaluating and updating. It is likely most will be native language implementation with FPGA support in the future. Languages like Java could possibly compete in this space but we need true concurrent collectors and control of memory layout. Getting this sort of support for managed runtimes would be great benefit to the world in general for high performance computing.

[Jan van Oort]

@Mike Yep, he has. I am using OpenHFT ChronicleMap right now to build a LRUCache<byte[], Object >. 

99-percentile latency is down to 6 µs on a Windows 7 / Core-i7 / SSD laptop with a Hotspot JVM :-)

Fortuna audaces adiuvat - hos solos ? 

[Jimmy Jia]

Island/Instinet/NASDAQ was famously Java-based, at least originally. They have FPGA ITCH ports now, but their core systems are still in Java.

Otherwise my rhetorical question of "why don't NASDAQ use Zing" would have been a complete non-sequitur.

[Gil Tene]

Wow. I go diving (I'm on vacation) and skip looking at the list for 24 hours, and this thread happens... Cool to see people stepping in to answer with their actual knowledge of Zing use in FinServ.

BTW, does anyone know who this Janny guy is, and if he actually works in HFT? Because I have never heard that he actually does ;-)

Janny, I'm obviously not going to list banks that use Zing, and what they each actually do with it. But here are some statements that I can make:

1. To your question about "biggest banks": MOST of the world's largest investment banks currently use Zing. [you can look up "largest investment banks", and "most" elsewhere ;-) ]. So now you can't honestly say "...I have never heard that the biggest banks use it." because you heard it here, and not just from me.

2. Zing is certainly used in HFT (and other latency sensitive trading platforms), but there are plenty of other things FinServ firms do with it.

3. FinServ represents a good chunk of Zing use and business, but it is NOT the majority (for either). There are plenty of response-time sensitive businesses and applications out there, and the fact that Zing trivially eliminates *ALL* GC-related glitches is useful across a wide breadth of applications and industries. Whether your definition of an unacceptable glitch (or 99.9%'lie) is 1msec, 10msec, 100msec, 1 sec, or 10 sec, and whether your heap size is 1GB, 10GB, 100GB, or 1TB, Zing will tend to get you to where you need to be quicker and cheaper.

4. Yes, there are some very smart people out there that have written zero-allocation Java for HFT and other trading platforms. Most of them did so because/when Zing was not an option. And most of our lowest-latency-telorating customers use Zing because they can now *avoid* much of the effort they had to apply before using it. They can build code and get to market faster, with fewer bugs, and with fewer people. And they can apply the actual power of their modern commodity computers and very smart engineers to competitive advantage, rather than wasting resources re-solving a now-solved problem over and over again.

5. The reason you don't see job postings for "Zing" skills is that using Zing does not require any "Zing skills". You deploy stuff just like you would with any other JDK (except that you spend a lot less time tuning), you write regular Java code (there are no Zing libraries or APIs), and your Java things just work right without needing those special "low latency" rules like "don't use more than X heap" or "Don't allocate more than Y/sec" to avoid annoying pauses at any level. To be clear, to write good low latency code you still need to be smart, and still need to write performant code, but those nonsense practices that were simply there to work around broken garbage collectors (ones that pauses when you do normal Java things) are simply a thing of the past. Unless you like to live in the past.

[Janny]

Hi Gil, 

Do you think you sound defensive by telling people that you don't know them only because they question facts about Azul?

If you tell me:

"very smart people out there that have written zero-allocation Java for HFT and other trading platforms"

I may clearly read it that Zing should be very carefully evaluated given the price and other benefits before moving to it and for the most project the safest option still will be Sun JDK with very smart people out there.

One more things: narrow focused companies like yours are very keen to get approval from customers to tell that they use their technology. Zing is not something secret and specific for companies not to give approval for it. On this webpage I can only see Credit Suisse (and for slow Fixed Income trading, not for FX and Equities) and Barclays: http://www.azulsystems.com/content/case-studies.

I'm very sceptical here only because of facts, I can't buy something only because mere mortals Martin or Gil said it is cool.

[Greg Young]

As someone who has been a vendor in similar industries the first clause added in almost every contract is "never say who we are". To be fair competive advantage is often involved. Its tough from a vendor pov.

--

[Greg Young]

On a side note its even more fun when you randomly run into 3 clients from 3 places while out for a pint and have to do introductions...

Greg

Gil,martin ill owe you a beer for the coffee you just laughed up reading this :)

[Gil Tene]

On Thursday, February 19, 2015 at 2:17:43 AM UTC-4, Janny wrote:

Hi Gil, 

Do you think you sound defensive by telling people that you don't know them only because they question facts about Azul?

I don't know. Do you think you sound defensive by saying that people must not be using the latest cool technique for eliminating outliers in Java HFT systems just because a few of your closest friends haven't heard of it being used in big banks? ;-)

Note the winky-face at the end of that sentence. There was one at the end of the "...Because I have never heard that he actually does." one below too. I was simply using your original question's logic and wording, with you as the subject, to make a point...

If you tell me:

"very smart people out there that have written zero-allocation Java for HFT and other trading platforms"

I may clearly read it that Zing should be very carefully evaluated given the price and other benefits before moving to it and for the most project the safest option still will be Sun JDK with very smart people out there.

The safest option is Zing AND the very smart people. Zing lets those smart people work on other stuff that really matters, and stop wasting their time writing to fit into 640KB heaps, or avoiding pressure on those poor garbage collectors.

Evaluating any product carefully is always a good idea. And since we know that it really does what we say it does, we love such evaluations.

As for price, Zing is arguably dramatically under-priced for HFT, since we don't have separate pricing for trading systems, and people in industries and applications that have far less money on the line than in HFT find it extremely cost-efficient.

 

One more things: narrow focused companies like yours are very keen to get approval from customers to tell that they use their technology.

Narrow focused? You think "all of Java applications on servers" is narrow? Or maybe that GC only bothers a few people in the Java world?

Zing is not an HFT JVM, or a FinServ JVM. It's a JVM that doesn't pause. There are many more people using it for that outside of FinServ than within. It just happens to solve one of the biggest pain points for using Java in HFT (and other low latency trading systems), which is why for people who write HFT and also code it tends to be a no-brainer.

And yes, we are very keen to get approval, and love it when customers talk about their success in public. Unfortunately, most FinServ companies (and many non FinServ) don't like doing that for all sorts of reasons (competitive edge, brand issues, appearance of endorsement). That's why I love it when I get a chance to do talks like this one: http://qconlondon.com/presentation/low-latency-java-real-world with customers who are willing to tell the world about the innards of what they do.

 

Zing is not something secret and specific for companies not to give approval for it. On this webpage I can only see Credit Suisse (and for slow Fixed Income trading, not for FX and Equities) and Barclays: http://www.azulsystems.com/content/case-studies.

I didn't say "of the world's largest investment banks currently talk publicly about using Zing and allow case studies about their trading systems, showing before/after improvements and such". I simply said "most of the world's largest investment banks currently use Zing." You can choose to not believe me (I do work at Azul), and you can choose to attribute anything others say to "Azul asked them to say that". But why ask this list then? 

I'm very sceptical here only because of facts, I can't buy something only because mere mortals Martin or Gil said it is cool.

Well, it's your right to ask a question on this list ("Just curios are there any examples of Azul usage in HFT?") and then ignore all the answers you get, I guess. 

I certainly wouldn't expect you to buy something because I said it is cool. But when Martin says so, I'd hope you'd give it a try on the hope that it will save you lots of pain, time and money. And then buy it if it actually works.

[Janny]

This was a good answer. Anyway, I'm not here to prove that we don't need Azul, I'm personally keen to give it a try and avoid all GC pain and other workarounds and have a good performance in the project I work on, but my company may have a different view from economical and other perspectives. I know trading market very well: you build products for many industries, I build products for one trading industry for a long time and I know quite many people from this business and not just a few friends. As for your presentation, it is cool that LMAX uses Zing, but for me LMAX is not a big thing yet: they are growing, but serious corps decide to add LMAX to the liq. pool usually as the last thing among tens of other providers - this is current state of affairs, because they are more like a big retail broker currently: they are nowhere near with NASDAQ or Currenex by volume and retail clients do not know what does HFT means.

I think I'm done with this and for Martin - I'm not up to LMAX debates.

Cheers.

[Gil Tene]

LMAX is not our biggest customer, by far, and not the largest exchange or venue using Zing. But LMAX is very open about what they do, are willing to go on the record about their use of Zing, and willing to do public talks about their very real experiences with it and the lessons learned (both good and bad). I'll take that all day long, and I wish more of our FinServ customers were willing and able to do the same.

As it stand though, here are some simple summary points (in anonymous quote form"I got from people at two different customers who are investment banks on those various "largest in the world" lists. You can believe them or not, but they are each from an actual large bank doing actual HFT or Algo trading with Zing:

- "Anyone writing new Java code for trading systems without planning to use Zing to run it is wasting precious engineering resources."

- "I think that if you are looking for a job writing Java code in New York in FinServ these days and you don't know what Zing is (don't have to have used it), you won't get the job."

- "We have some of the smartest people working for us, but we can now get our algos to market about 20% faster..."

- "The impact on the first 5000 orders of the day is huge."

[The second one is my favorite one].

[Jimmy Jia]

Janny - Just to spell this out one more time: a lot of the established players don't use Zing because they've gone through a huge amount of effort to make their code never GC anyway. If you asked the people who built Island what they'd use if they were building a new exchange in Java from scratch, they'd probably tell you that they'd go with Zing and not go through all the effort with avoiding the GC the first time around. They're not in that world, though.

[Kirk Pepperdine]

I

 have to say I’ve found this thread contains unwarranted trolling. I’ve run into Zing at a number of different client sites and as Gil has eluded, these are under NDA which means I can’t say much about where they are. All I know is that Gil has been honest and forthright in all of his postings.. I hope the trolling stops.

— Kirk

[Kedar Bhat]

My entire career has been in the low latency space (about 9-10 years). I've used Java, C, and C++, sometimes simultaneously. Low latency is an ambiguous term, depending on the exchange/endpoint and asset class with which you are dealing.

As noted in other posts, when speaking about large organizations (or even small organizations), one department/group/team may be using something entirely different from what the others are using, so a blanket statement about one particular organization can be problematic.

One thing I should also note is that unless you are trying to compete with the fastest (say) 1% of low latency competitors, the choice of Java, C, or C++ will make less of a difference than the robustness of strategies being employed. If you ARE trying to compete with the fastest (say) 1% of low latency competitors, there are other parts of your technology stack that can have a massive impact on your success even if everything at the strategy/alpha level is handled in the best possible way. Having used Java, C and C++, I invariably found good use of algorithms and data structures to be the biggest factor in strategy success (from a speed standpoint -- this, of course, assumes the strategy itself was sound). I also spent an inordinate amount of time trying all sorts of (idiotic) ways to "optimize" code (Java code in particular), which bought me much less (especially for the time spent) than focusing on data structures and algorithms.

Also, why would a job description mention Zing? As noted by other posters, Zing is meant to allow a developer to write idiomatic Java without spending 90% of his time trying to make Java not be Java. A job opening involving Java development (or any development role meant for a low latency environment) would probably be more deeply involved with writing efficient code, not writing for a specific compiler or virtual machine. Also noted by other posters, Zing shouldn't require the same level of fine tuning as does Hotspot, which is why tuning Hotspot might actually appear in a job description, and why Zing wouldn't.

On Wednesday, February 18, 2015 at 8:08:55 AM UTC-6, Janny wrote:

This is all good in theory, but in practice if a good number of banks uses Zing, why I have never heard about it?

Someone from my friends who work in other banks or hedge funds would definitely mention it. I went through many interviews with big banks for equities and FX trading in the past, but have never heard a world about Zing. Here where I live all these hedge funds and big banks don't afraid to mention about fpga, C++, STL or just core java, kdb+ for HFT roles - but they don't mention Zing in the job descriptions. I know what kind of projects we have in our company and what kind of technologies we use. Nobody will be using Zing, for example, for fixed income trading, usually for Equities and FX (the usage is quite narrow, so not so many departments in the banks who potentially may use it). I'm very very sceptical...

On Wednesday, February 18, 2015 at 9:47:55 PM UTC+8, Jan van Oort wrote:

Coincides 100% with my experience with large insurers and banks. One department may have been using X with great success, with another department struggling to choose between Y and Z. 

Fortuna audaces adiuvat - hos solos ? 

On 18 February 2015 at 14:20, Jean-Philippe BEMPEL <jpbe...@gmail.com> wrote:

On Wednesday, February 18, 2015 at 12:10:04 PM UTC+1, Martin Thompson wrote:

 Also consider that the biggest banks are also very big. This means that they will not use the same technology in every department. In my experience it is not uncommon for one department to not know what other departments are doing.

+1000 on this statement, This is without doubt the reason of this discrepancy :) 

-- 
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

On Wednesday, February 18, 2015 at 8:08:55 AM UTC-6, Janny wrote:

This is all good in theory, but in practice if a good number of banks uses Zing, why I have never heard about it?

Someone from my friends who work in other banks or hedge funds would definitely mention it. I went through many interviews with big banks for equities and FX trading in the past, but have never heard a world about Zing. Here where I live all these hedge funds and big banks don't afraid to mention about fpga, C++, STL or just core java, kdb+ for HFT roles - but they don't mention Zing in the job descriptions. I know what kind of projects we have in our company and what kind of technologies we use. Nobody will be using Zing, for example, for fixed income trading, usually for Equities and FX (the usage is quite narrow, so not so many departments in the banks who potentially may use it). I'm very very sceptical...

On Wednesday, February 18, 2015 at 9:47:55 PM UTC+8, Jan van Oort wrote:

Coincides 100% with my experience with large insurers and banks. One department may have been using X with great success, with another department struggling to choose between Y and Z. 

Fortuna audaces adiuvat - hos solos ? 

On 18 February 2015 at 14:20, Jean-Philippe BEMPEL <jpbe...@gmail.com> wrote:

On Wednesday, February 18, 2015 at 12:10:04 PM UTC+1, Martin Thompson wrote:

 Also consider that the biggest banks are also very big. This means that they will not use the same technology in every department. In my experience it is not uncommon for one department to not know what other departments are doing.

+1000 on this statement, This is without doubt the reason of this discrepancy :) 

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

[Martin Thompson]

+1 and a big :-)

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.

[Aldo Garcia]

FWIW, I work at a large bank. I work with Azul every day.

We use Azul in equities, FX, FICC, across at least 20 applications.

I accepted the job *because* it would give me the chance to work

with Zing. After two years using Azul's Vega hardware at a high traffic web shop 

I wanted to see for myself whether or not the great-in-theory Zing actually worked.

It does.

I work with apps that have 128GB heaps and sub-millisecond GC pauses.

That's as close to magic as anything I've seen. It's an awesome JVM, and like the 

OP, I am a little surprised that I don't see Zing on job postings, given that it is used,

and does, to some degree , require specialist knowledge to get the best from it.

And yes, there are plenty of developers here who don't know that we use Azul.

Aldo

PS - this is a pseudonym for obvious reasons