Imported from previous forum
After seeing a lot of complaints about FAST on this forum, I’d first like to say to the creators that I personally like FAST encoding. At first I was taken aback by the complexity, which I think is the source of most complaints. However once I had a full understanding of the specification, I realized the beauty of FAST and without it’s complexity it would never be able to accomplish what it does.
I do have one comment or question though… Why does the template id field come after the PMAP? Is there an implementation of FAST which does not use templates?
The reason I ask is because in my FAST decoder there is no way I can figure to decode without first looping through the PMAP to see if the template id is present, looking for the stop bit, extracting the template id, then starting all over (now that I know the template id) and reparsing the PMAP along with skipping over the template id.
To me this seems inefficient to loop through the same bytes twice. Everywhere else my decoder never touches the same bytes twice. I really can’t figure there is a solution to this, but maybe I’m wrong? Anyway, if there was one change I could make, that would be to have the template id be a mandatory field which precedes the PMAP and also remove the template id bit from the PMAP.
The tid appears after the pmap so it can be optimized away most of the time using the implicit copy operator. It not only saves you bytes on the wire, it also allows you to save table lookups and similar operations depending on your implementation.
Not sure what you mean by reading the pmap twice though. Every implementation I’ve seen so far do the stop bit scanning once, store the bits in some way or other, then access the stored bits in order. So if you mean memory/register accesses I’d say there is at least one for every bit in the pmap. Even if you don’t use intermediary storage for the decoded pmap, you should get away with finding its length once. And I don’t see how the placement of the tid would change that.
/David
After seeing a lot of complaints about FAST on this forum, I’d first
like to say to the creators that I personally like FAST encoding. At
first I was taken aback by the complexity, which I think is the source
of most complaints. However once I had a full understanding of the
specification, I realized the beauty of FAST and without it’s complexity
it would never be able to accomplish what it does.I do have one comment or question though… Why does the template id
field come after the PMAP? Is there an implementation of FAST which does
not use templates?The reason I ask is because in my FAST decoder there is no way I can
figure to decode without first looping through the PMAP to see if the
template id is present, looking for the stop bit, extracting the
template id, then starting all over (now that I know the template id)
and reparsing the PMAP along with skipping over the template id.To me this seems inefficient to loop through the same bytes twice.
Everywhere else my decoder never touches the same bytes twice. I really
can’t figure there is a solution to this, but maybe I’m wrong? Anyway,
if there was one change I could make, that would be to have the template
id be a mandatory field which precedes the PMAP and also remove the
template id bit from the PMAP.
Thanks for the response David,
To clarify, yes it’s not finding the length of the PMAP that bothers me. My implementation does not access outside memory for storage so I must loop through the PMAP bits twice.
So lets look at the type of implementation you mentioned, they scan the bits first and store them in some way (ie copy them to another memory location), but because they don’t know what the template id this will require them to access that storage memory again to update the template fields once the template id is found (probably resulting in a second memory copy). So even in the scenario you mention, the decoder must reread the bits again from the storage memory (which is equal to looping twice) to update the individual template fields with their PMAP bits.
I hope that make sense. Really though, it’s not a big deal, the processing time is very minimal. I was just curious why the template id is stored where it is, as it is clear the template id must be known to do anything with the PMAP at all. That’s why I was suggesting that if there is to be another FAST version, it might be a good update to move the template id to the beginning of the message and you can even set it to NULL if it is to be copied from a previous message.
Brandon
The tid appears after the pmap so it can be optimized away most of the
time using the implicit copy operator. It not only saves you bytes on
the wire, it also allows you to save table lookups and similar
operations depending on your implementation.Not sure what you mean by reading the pmap twice though. Every
implementation I’ve seen so far do the stop bit scanning once, store the
bits in some way or other, then access the stored bits in order. So if
you mean memory/register accesses I’d say there is at least one for
every bit in the pmap. Even if you don’t use intermediary storage for
the decoded pmap, you should get away with finding its length once. And
I don’t see how the placement of the tid would change that./David
After seeing a lot of complaints about FAST on this forum, I’d first
like to say to the creators that I personally like FAST encoding. At
first I was taken aback by the complexity, which I think is the source
of most complaints. However once I had a full understanding of the
specification, I realized the beauty of FAST and without it’s
complexity it would never be able to accomplish what it does.I do have one comment or question though… Why does the template id
field come after the PMAP? Is there an implementation of FAST which
does not use templates?The reason I ask is because in my FAST decoder there is no way I can
figure to decode without first looping through the PMAP to see if the
template id is present, looking for the stop bit, extracting the
template id, then starting all over (now that I know the template id)
and reparsing the PMAP along with skipping over the template id.To me this seems inefficient to loop through the same bytes twice.
Everywhere else my decoder never touches the same bytes twice. I
really can’t figure there is a solution to this, but maybe I’m wrong?
Anyway, if there was one change I could make, that would be to have
the template id be a mandatory field which precedes the PMAP and also
remove the template id bit from the PMAP.
That’s why I was suggesting that if
there is to be another FAST version, it might be a good update to move
the template id to the beginning of the message and you can even set it
to NULL if it is to be copied from a previous message.
That doesn’t make sense. A NULL value means the field is not present in this record. The TID must be present.
A zero PMAP bit for a field means the field is not present on the wire. To answer your earlier question, "Yes there are FAST data sources that omit the TID on the wire, relying on the implicit copy operator for the template ID. For this to work, the PMAP must come first.
If this is a problem for your implementation, I might respectfully suggest you change your implementation rather than trying to change the protocol.
Dale
I’m resigning trying to explain my point. It doesn’t seem like anyone wants to actually read what I’m saying. I was honestly trying to help the protocol be more efficient so for anyone taking offense to my comments please don’t.
Oh and for the record I have not a clue what Majkara is talking about.
Brandon
That’s why I was suggesting that if there is to be another FAST
version, it might be a good update to move the template id to the
beginning of the message and you can even set it to NULL if it is to
be copied from a previous message.That doesn’t make sense. A NULL value means the field is not present in
this record. The TID must be present.A zero PMAP bit for a field means the field is not present on the
wire. To answer your earlier question, "Yes there are FAST data sources
that omit the TID on the wire, relying on the implicit copy operator for
the template ID. For this to work, the PMAP must come first.If this is a problem for your implementation, I might respectfully
suggest you change your implementation rather than trying to change
the protocol.Dale
Brandon,
your point is valid and I don’t think your comments have offended anyone. We actually had the tid before the pmap in one of our test versions of the protocol during development back in 2005. Then we found that on some actual live data (ARCA if I recall correctly), we could save 5-10% of the transfer size. So we decided to put the tid after the pmap, thus being able to use copy coding. This decision was based on our empirical tests, and I believe that we were able to show that this arrangement had a marginal impact on performance.
Best,
Rolf
I’m resigning trying to explain my point. It doesn’t seem like anyone
wants to actually read what I’m saying. I was honestly trying to help
the protocol be more efficient so for anyone taking offense to my
comments please don’t.Oh and for the record I have not a clue what Majkara is talking about.
Brandon
That’s why I was suggesting that if there is to be another FAST
version, it might be a good update to move the template id to the
beginning of the message and you can even set it to NULL if it is to
be copied from a previous message.That doesn’t make sense. A NULL value means the field is not present
in this record. The TID must be present.A zero PMAP bit for a field means the field is not present on the
wire. To answer your earlier question, "Yes there are FAST data
sources that omit the TID on the wire, relying on the implicit
copy operator for the template ID. For this to work, the PMAP must
come first.If this is a problem for your implementation, I might respectfully
suggest you change your implementation rather than trying to change
the protocol.Dale
Thanks Rolf, I thought I was going crazy there for a second. Your post has thoroughly answered my question. As for causing offense, I think I was confusing replies directed towards another poster on this thread.
What I meant in my earlier post about just set the tid to NULL, is that the NULL value of the tid (if it were to precede the pmap) could imply it is to be copied (so worst case it would take 1 byte). The reason this could work is because the tid would no longer be a normal field as it does not follow the pmap and to answer Dale’s response what would the sense of NULL for the tid meaning “not present” be when every FAST message must have a template associated with it to be decoded?
Anyway, I was unaware that you guys had thought about this, so if it wasn’t found beneficial in 2005 then it probably won’t in the future.
Thanks for listening Rolf,
Brandon
Brandon,
your point is valid and I don’t think your comments have offended
anyone. We actually had the tid before the pmap in one of our test
versions of the protocol during development back in 2005. Then we found
that on some actual live data (ARCA if I recall correctly), we could
save 5-10% of the transfer size. So we decided to put the tid after the
pmap, thus being able to use copy coding. This decision was based on our
empirical tests, and I believe that we were able to show that this
arrangement had a marginal impact on performance.Best, Rolf
I’m resigning trying to explain my point. It doesn’t seem like anyone
wants to actually read what I’m saying. I was honestly trying to help
the protocol be more efficient so for anyone taking offense to my
comments please don’t.Oh and for the record I have not a clue what Majkara is talking about.
Brandon
That’s why I was suggesting that if there is to be another FAST
version, it might be a good update to move the template id to the
beginning of the message and you can even set it to NULL if it is
to be copied from a previous message.That doesn’t make sense. A NULL value means the field is not present
in this record. The TID must be present.A zero PMAP bit for a field means the field is not present on the
wire. To answer your earlier question, "Yes there are FAST data
sources that omit the TID on the wire, relying on the implicit copy
operator for the template ID. For this to work, the PMAP must come
first.If this is a problem for your implementation, I might respectfully
suggest you change your implementation rather than trying to change
the protocol.Dale
Hi Brandon,
I’m resigning trying to explain my point. It doesn’t seem like anyone
wants to actually read what I’m saying.
It sounds like my comment came across with the wrong tone. Sorry.
When I used the word “respectfully” it was literal. I was not being sarcastic! Given the other conversation going on [1] I was trying to make it clear that my statement respected your proposal even though I was offering a counter argument.
The point I was trying to make – putting the PMAP first improves compression for some cases – I believe Rolf covered.
Dale
[1] I believe I can summarize Majkara’s recent emails in four words without loss of content: “I don’t like FAST.”
Thanks Dale,
Yes it did sound sarcastic to me. I think I was feeling a little sensitive as my implementation of FAST was something I took a great deal of care on building. Which is why I brought up the point I did, as out of the entire FAST spec, the placement of the template id is the only thing that seemed wrong to me.
Anyway, thanks again for letting me know there was no harm intended and for the summarization of Majkara’s comment.
Brandon
Hi Brandon,
I’m resigning trying to explain my point. It doesn’t seem like anyone
wants to actually read what I’m saying.It sounds like my comment came across with the wrong tone. Sorry.
When I used the word “respectfully” it was literal. I was not being
sarcastic! Given the other conversation going on [1] I was trying to
make it clear that my statement respected your proposal even though I
was offering a counter argument.The point I was trying to make – putting the PMAP first improves
compression for some cases – I believe Rolf covered.Dale
[1] I believe I can summarize Majkara’s recent emails in four words
without loss of content: “I don’t like FAST.”
[1] I believe I can summarize Majkara’s recent emails in four words
without loss of content: “I don’t like FAST.”
I actually re-read his post to make sure I didn’t miss any interesting, intriguing or inspiring piece hidden behind the impertinence, innuendo, insults and incorrect statements. I came up with the following questions that I don’t really have a good answer for. This doesn’t mean that any of the questions is relevant, but I find them “interesting” in a way:
- What is the “exact” processing overhead of FAST field and transfer encoding respectively?
As those of you who have been involved for some time know, we didn’t really focus on speed at the outset, but rather on descent encoding compactness and ease of use. Numbers quoted so far have been the total for both field encoding and transfer encoding, as that is what matters in real life. But when I read his post saying “14 million/s”, “15 fold reduction”, “environment factors”, “factor of 100”, it strikes me as pure conjecture. The numbers are definitely wrong as they are not even close to what we saw in our testing.
But given different work loads, what are the actual numbers?
We know from a number of implementers that they have succeeded in getting very good performance.
As people are getting more experience with how to implement FAST, I expect to see even higher performance. The evolution on the hardware side seems to work for us. I have personal experience of the speed improvements offered by Intel processors over the last five years.
There’s an interesting discussion going on over at LinkedIn. It was started by Malcolm Spence of Object Computing, Inc. and he has shared some interesting data points relating to recent performance testing done at OCI.
I will make a note to myself that I need to revisit the tests we did a few years ago. I’ll let you know if and when I have had time to do some new testing.
- To what extent and in which ways does the serial nature of FAST create problems for implementers and users?
- Are there ways that we can improve the situation?
- Is it possible to improve without creating compatibility problems?
Our hypothesis is that we should not change the FAST Protocol without very good reason. People have been very clear that they prefer a stable protocol and better docs.
I’m working together with the core mdowg group to improve documentation, presentation and training materials to improve the learning curve for new-comers, as well as encouraging existing implementers to be able to reap the full benefit of FAST.
We welcome any comments and suggestions on what to include in the work that we currently do.
That said, I think that posts like Brendan’s post above regarding tid and pmap placement are important. They force us to re-visit previous discussions and to re-examine previous results and views.
I welcome any post that challenges the current state in a constructive manner and I will do my best to account for what we did earlier. I want this to be a forum where people feel encouraged to ask questions.
Other than that, I can only wish Mr Majka the best of luck and I hope he finds some peace of mind. I will not hold my breath, but I would not be surprised if he could contribute if he stopped being nasty and started keeping his eyes on the ball.
The rest of us are here for a reason.
Best,
Rolf
[1] I believe I can summarize Majkara’s recent emails in four words
without loss of content: “I don’t like FAST.”I actually re-read his post to make sure I didn’t miss any interesting,
intriguing or inspiring piece hidden behind the impertinence, innuendo,
insults and incorrect statements. I came up with the following questions
that I don’t really have a good answer for. This doesn’t mean that any
of the questions is relevant, but I find them “interesting” in a way:
- What is the “exact” processing overhead of FAST field and transfer
encoding respectively?
As those of you who have been involved for some time know, we didn’t
really focus on speed at the outset, but rather on descent encoding
compactness and ease of use. Numbers quoted so far have been the total
for both field encoding and transfer encoding, as that is what matters
in real life. But when I read his post saying “14 million/s”, “15 fold
reduction”, “environment factors”, “factor of 100”, it strikes me as
pure conjecture. The numbers are definitely wrong as they are not even
close to what we saw in our testing.But given different work loads, what are the actual numbers?
We know from a number of implementers that they have succeeded in
getting very good performance.As people are getting more experience with how to implement FAST, I
expect to see even higher performance. The evolution on the hardware
side seems to work for us. I have personal experience of the speed
improvements offered by Intel processors over the last five years.There’s an interesting discussion going on over at LinkedIn. It was
started by Malcolm Spence of Object Computing, Inc. and he has shared
some interesting data points relating to recent performance testing
done at OCI.I will make a note to myself that I need to revisit the tests we did a
few years ago. I’ll let you know if and when I have had time to do some
new testing.
- To what extent and in which ways does the serial nature of FAST create
problems for implementers and users?- Are there ways that we can improve the situation?
- Is it possible to improve without creating compatibility problems?
Our hypothesis is that we should not change the FAST Protocol without
very good reason. People have been very clear that they prefer a stable
protocol and better docs.I’m working together with the core mdowg group to improve documentation,
presentation and training materials to improve the learning curve for
new-comers, as well as encouraging existing implementers to be able to
reap the full benefit of FAST.We welcome any comments and suggestions on what to include in the work
that we currently do.That said, I think that posts like Brendan’s post above regarding tid
and pmap placement are important. They force us to re-visit previous
discussions and to re-examine previous results and views.I welcome any post that challenges the current state in a constructive
manner and I will do my best to account for what we did earlier. I want
this to be a forum where people feel encouraged to ask questions.Other than that, I can only wish Mr Majka the best of luck and I hope he
finds some peace of mind. I will not hold my breath, but I would not be
surprised if he could contribute if he stopped being nasty and started
keeping his eyes on the ball.The rest of us are here for a reason.
Best, Rolf
Just for the record (Rolf mentioned us) we developed an open source C++ implementation of FAST. We have been testing it on 3Ghz systems and getting sub microsecond speeds for decoding per message. CME is the only exception so far and even it is at 2.7 microseconds.
Our users seem happy. They get to use FAST on multiple exchanges with only slight modifications,and as part of the overall feed handling budget “market data arrival to trader desktop”, FAST decding is now in the noise. There are other more serious issues to focus on that consume microseconds!
regards Malcolm Spence
Object Computing Inc. St. Louis MO USA
that I don’t really have a good answer for. This doesn’t mean that any
of the questions is relevant, but I find them “interesting” in a way:
- What is the “exact” processing overhead of FAST field and transfer
encoding respectively?
[…]
But given different work loads, what are the actual numbers?
Here are some actual numbers from our system in production for Eurex and Xetra:
The total time from the end of the incoming multicast packet to the start of the output packet: 480ns for the whole packet with a standard deviation of around 200ns.
This includes the multicast stack, the FAST decoding, the order-book processing and reconstruction, the output generation and the output multicast stack.
CME will be similar.
So yes, FAST is fast 
Marc
to put this in perspective, if you look at the propagation delay in a fiber connection, the light travels on the order of 100 meters in 480ns.
(speed of light in vacuum is roughly 30 meters / 100 ns, and speed is reduced by ~1/3 in fiber)
The standard deviation is obviously lower in this case 
/Rolf
Here are some actual numbers from our system in production for Eurex
and Xetra: The total time from the end of the incoming multicast
packet to the start of the output packet: 480ns for the whole packet
with a standard deviation of around 200ns.This includes the multicast stack, the FAST decoding, the order-book
processing and reconstruction, the output generation and the output
multicast stack.CME will be similar.
So yes, FAST is fast
Marc
- What is the “exact” processing overhead of FAST field and transfer
encoding respectively?
I may have been somewhat imprecise or implicit when posing the question above. There are several different questions embedded here:
- What is the processing overhead of the field encoding?
- What is the processing overhead of the transfer encoding?
- How does the processing overhead vary depending on the input data?
- How does the processing overhead of the transfer encoding vary depending on the processing overhead of the field encoding?
A variation of q4 could be: How does the processing overhead of field encoding and transfer encoding respectively correlate for individual messages?
I recall that during testing in June 2005, we found a few cancel messages in the ARCA test data set that ended up being encoded as a pmap only. Every field (incl the tid) was defaulted after field encoding. So, while field encoding took some resources comparing and making the decision to default code each field value, the transfer encoding ended up passing a one-byte pmap. Obviously, this only happened very rarely, I believe we found less than a handful in the 77-million or so real messages used for testing of the ARCA feed.
/Rolf
Some bold statements there (and in typical “enlightened by FAST or FIX” fashion, completely missing out on what should be the primary concern).
First of all the theoretical maximum for a trivial work and size, tad above nop op and word-size, i/o messaging on latest CPUs and architectures is circa 14million/s per core. What you incur with the best of FAST implementations out there is a 15 fold reduction for
trivial messages. This brings you to sub 1 million per core for sure. Bring in environment factors and you will witness it drop much further.
Unless you are dreaming that message is a field or those messages cannot be complex enough to slow you by another factor of 100, then sure you are ‘right’, a nop-like trivialities decode at that speed, duh!
However, it is not a constant by any means, so I don’t know how anyone can deliver any complexity or latency observation on it but trivial data (and marketing it via a yet another fair-practice firm like Intel).
You guys should simply benchmark yourself against a mixed stream of Eurodollar and Crude contract and let us know, what the rate is,
on a volatile day sample of 4GB. Best of all randomize it across huge range days (oh I forget FAST is as serial as a Kellogs cornflake).
But, this will give you the latency and bandwidth reduction we can then compare against an alternative that will beat the Fast VMs or other impls by a factor of 100 in latency and bandwidth reduction: Apples vs Apples. Once again, this has been done, so whenever you are ready… And for heaven’s sake make the sample public so we can start something other than fanboy, non-critical and subjective demonstration of solution to the CEO problems.
Claiming 7M+ msgs or even 5M+ msgs/second is Cloudy Reasoning at best, and for any sufficiently complex CME stream. For the record, if you want lowest latency get everything out of the FAST encoding and be done, which shows the point of FAST being pointless.
So where is the problem again? Do not target bits or tags or hacks of bad designs; target the domain that’s the problem (simple pre-graduate level mistakes FIX and FAST keep repeating).
FAST did some better typing but miserably fails with basics such as enumerations, decimal-equity reasoning etc while complicating to oblivion and making, serial->serial->serial->serial type of processing the new 2010+ trend.
Same old from same old guys, and 5 to 10 years later you still do not satisfy basic semantics, mechanics or models of anything but equities (which themselves give you integration headaches on a ‘standard’). Hell of a long time to keep messing up but that is not all.
Extensions keep appearing which tells you a lot, all while not satisfying trivial exchange processing but messing up with volumes of pdfs and hacky, misunderstood and misapplied XML or templates or tags or bit jokes. Java consultant influences are at work here making it a non-brainer it will be bloated.
Do we even need to get started on things:
-
Like use of XML comments, specific formatting in comments, and unstructured and messed up data to denote specific versions, types and transport detail.
-
Like using undergraduate level XML for template definitions design (you know, rather than an invention that is at complete odds to its deduction of fields rather than types and fighting the InfoSet ideas ).
-
Like avoiding use of decimal, something that plagues minds of people who obviously believe Stock marketplace is the only one (OMXs and eSpeeds and other nonsense). And not forgetting floating-point ‘scientists’ fighting the digital space.
-
Like duplication that is everywhere in terms of FIX field target and template name target, whilst it all has an ID because someone really smart invented a tag/value mapping and called it : FIXammer.
-
Like avoiding Service Pack abominations and some seriously depleted designs that still do not satisfy basic object models of many trading places (this is again the fault of stock-based directors and consultants since the consortium inception and their technical incompetence).
-
Even FIX itself is challenged in integration with anything/anyone and after so many years of hacking new tags and no semantic mapping or better than hacker-style versioning (just look at the childish schemas they produce in their releases. )
-
Fixing and Fasting the PDFs, machine readability and rules ie. its vocabulary, formats and choice of some pretty dumb words while concepts are known and exist in computing for ages (but this is the COBOL-is-alive workforce behind it, it is too obvious).
-
Sealing the base standard and not allowing any deviation from it. If there is one, it is no longer a result of consortium work and must not be indorsed in any form or carry any of the logos or trademarks involved.
-
Transport Independence idea of 4th July kind, and putting it into context of FAST and FIX flaky design. Think about it, an oxymoronism.
-
Mixing up concepts in bits and meta expression.
11+ We could go on for another 100 points and couple of months of clear hacking instances.
Whatever you do, you should seriously consider the damage you have caused and will keep going before taking on board yet another ‘brilliant’ idea. You have to stop creating hacky tech for the sake of tech, and mega cost for the sake of cost. If you can get over
that you will progress, otherwise the whole industry is going down faster than banks did and your taxes and many new generations will pay for it, again.
And instead of investing in a Not-Invented-Here, broken, type system in bit-space (oxymoron), someone should seriously consider putting a halt to this mess of a charade. Yes many ‘designers’ and Java-bloat firms had their time and made a business out of it, but is that the end of it?
All those ‘solutions’ just to get a valid price or submit a market order!! You need a truck and a dozen libraries and VMs to kick it off? Plus, that price won’t last long in example of CME which does not even satisfy snail-level recovery response times. Plus, you do not solve the bandwidth problem as you can see from your exchange and telco requirements and costs.
It all clearly lead to this incompetent result and refusal to let the same mistakes ripple to infinity.
Anyone ever wondered why ( apart from incompetence and flaky domain knowledge hacking )?
Why, as in critically and without subjective reason to defend their own company/business or delusion of elitism or tehnically sound solution ?
You’re Welcome,
Le Sake Of Mankind
I am not able to figure out what you would like people to change or avoid but I am convinced that insulting an entire community will not get you there. That gives me comfort even though your approach is a real test to democracy and freedom of speech.
[ original email was from Toby Corballis - toby.corballis@rapidaddition.co.uk ]
> I am not able to figure out what you would like people to change or
avoid but I am convinced that insulting an entire community will not get
you there. That gives me comfort even though your approach is a real
test to democracy and freedom of speech.
I’m with Hanno on this… though I might go one step further and suggest that this samcks of a deliberate flame - something that was popular in the usenet groups of the early 90s and was considreed slightly juvenille even back then.
[ original email was from Mark Reece - mark.reece@hsbcib.com ]
I don’t know the original poster, however, I recollect a number of similar posts on this forum over the past 2 or 3 years with the same user name. Freedom of speech is one thing, constructive engagement is another. FPL, for me, is an industry group where people work to establish standards that work for the whole community. People provide their time because it is something which is important to them. While it is helpful for someone to politely point out that something could be better, but it is, in my personnal view, less helpful if that help stops before making concrete suggestions for the community to discuss - because that is the purpose the forum was established for.
I am not able to figure out what you would like people to change or
avoid but I am convinced that insulting an entire community will not
get you there. That gives me comfort even though your approach is a
real test to democracy and freedom of speech.
I’m with Hanno on this… though I might go one step further and suggest
that this samcks of a deliberate flame - something that was popular in
the usenet groups of the early 90s and was considreed slightly juvenille
even back then.
I must say it is quite difficult to follow the line of reasoning of this rant which is ripe with personal insults rather than constructive criticism.
One random comment is that although in general, serialization can be a limiting factor, it is clearly not the case here, as data partitioning can be - and is - used where relevant by exchanges (such as the CME and DB), thus parallelizing the FAST streams on a more appropriate level.
It is possible that there are some valid points in here (and I’m sure any good suggestions for improvement would be seriously considered), but without a civil tone and a structured approach to suggesting improvements, they are headed for the eternal bit-bucket.
Joakim
Some bold statements there (and in typical “enlightened by FAST or FIX”
fashion, completely missing out on what should be the primary concern).
[cut]
You’re Welcome, Le Sake Of Mankind