Slashdot Mirror
London Stock Exchange Rejects .NET For Open Source
ChiefMonkeyGrinder writes "This summer, the London Stock Exchange decided to move away from its Microsoft .Net-based trading platform, TradElect. Instead, they'll be using the GNU/Linux-based MillenniumIT system. The switch is a pretty savage indictment of the costs of a complex .Net system. The GNU/Linux-based software is also faster, and offers several other major benefits. The details provide some fascinating insights into the world of very high performance — and very expensive — enterprise systems. ... [R]ather than being just any old deal that Microsoft happened to lose, this really is something of a total rout, and in an extremely demanding and high-profile sector. Enterprise wins for GNU/Linux don't come much better than this."
Now how about my desktop?
De Icaza Responds:
Nooo, wait, come back. I found a way for people ditching Windows to keep using Microsoft technologies..
Please help publicise swpat.org - the software patents wiki
did Microsoft take down their triumphant "case report" on the original design-in?
Lacking <sarcasm> tags,
I think Microsoft needs to make sure they... Get The Facts. .... oh right
Mod me down, my New Earth Global Warmingist friends!
.Net is just a specification and a bunch of languages. There is an open source implementation of .Net itself and certainly many open source projects written in C#. "Rejects windows for open source" would have been a more appropriate headline. I hope they still use some kind of language with bounds checking and type safety, given the dangers of buffer overrun exploits in a national stock trading system.
Why is this news? Sun/Solaris dominated the high-end financial sector for ages...any exchange/trading house/equity firm/etc that is using Windows is insane IMHO. Linux is just the most recent unix platform to show up in the sector, it's not revolutionary...
I guess this would be a bad topic to bring up at a Windows7 launch party.
Nothing interesting to say...MUST...NOT...REPLY...ohtheheckwithit.
Didn't the New York Stock Exchange move over to Linux because Microsoft couldn't provide a good, low-latency RT kernel? They begged Microsoft, wanted to stay with Microsoft, and Microsoft couldn't provide them with a solution.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
yes.
Care to try a self-eating watermelon?
Get a web developer
TradElect platform, supplied by Accenture, has finally been answered: yes, it will. This hardly comes as a surprise â" the issue of the platformâ(TM)s speed and efficiency as well as Accentureâ(TM)s support has been a hot topic for the market in the last couple of months.
Accenture? Not exactly a low cost vendor there. Meaning, much of the "costs" of this .NET system is Accenture's high fees.
âWe want to address the entire suite of products and MillenniumIT gives us that scale.â(TM) Indeed, its offshore development centre â" âa hotbed of top graduatesâ(TM) â" with 94 per cent being top-class alumni from Sri Lanka and around the world, including MIT in the US, caters for such magnitude of scope.
Offshoring. They're going with a cheaper, although quite smart, set of folks.
Furthermore, he describes LSEâ(TM)s experience with .Net as âvery positiveâ(TM).
Ok, this looks more like changing vendors and implementation. They also want âfor more control, less costs, and the ability to build and innovateâ(TM).
This really isn't a damning of Microsoft and its technology. This is about going with a cheaper vendor and a software platform that gives them more control to suit their needs.
It's NOT me! It's the meds! I'm on 1000mg of Fukitol.
i read the article and found this.
while TradElect is based on Microsoftâ(TM)s .Net technology. The choice of the latter, which has raised quite a few eyebrows in the market, is defended by Lester. He claims that LSE is coming off TradElect not because of the .Net technology itself (although its trading speed is 2.7 milliseconds compared to Linux-based Chi-Xâ(TM)s 0.4 milliseconds), but âfor more control, less costs, and the ability to build and innovateâ(TM). Furthermore, he describes LSEâ(TM)s experience with .Net as âvery positiveâ(TM).
i will grant that the 2.7 ms benchmark is definately slower than .4 ms. However, i don't think you can benchmark the trading speed of .Net, only the trading speed of TradElect. Last time i checked msdn, there was no System.StockExchange namespace provided with the .net framework.
These articles sound more like MilleniumIT's just got a faster, nicer, cheaper product than TradElect. It sounds to me like Accenture failed, not .net
From what I understand, it was the app that sucked. Why is this then a stinging indictment of the platform?
"As God is my witness, I thought turkeys could fly." A. Carlson
Having read the article, and having traded equities on the London Stock exchange and Borsa Italiana for twenty years, I must say that I believe that the declaration that it was not a performance issue is correct.....to the point that I suspect that no amount of performance gains on Microsoft's part would have turned the scales.
Stock Exchanges are not national monopolies anymore, even if the few remaining big ones are gobbling each other. Controlling the technology involved is much more important than a slight performance hit. The London stock exchange scores a double hit on this one, since not only it will own the system, but the internals of said system will be open source, freeing it for example from limitation of sale to third parties by the US government. And anyway, when an istitution that big uses only Microsoft inhouse, is like having another stakeholder on your back, with an agenda of its own, like having you switch soon to the latest and greatest of its Server suite, if only for its publicity value. By doing the move, LSE is back to setting its own pace. I wish I could do the same on my desktop in the office.
"If a boss demands loyalty, give him integrity. But if he demands integrity, give him loyalty." (John Boyd, 1927-1997)
How disingenuous.
While it is 2.3ms faster it is also compared to 0.4ms (vs 2.7) making it 6.75 *times* faster.
Sub ms latency in trading is a critical requirement for this application and .net on windows just wasn't up to the task.
As a performance expert, this doesn't surprise me. In my opinion, current .net implementations are fundamentally unsuited to hard RT.
Ian Ameline
Hehe:) For those that are interested, they still have a InfoElect case study from 2006 posted on their site, which I believe was the the precursor to TradElect.
You didn't read the article did you?
It was cheaper for them to buy the WHOLE COMPANY that had built this technology, than it was to continue running/maintaining a .NET application. The .NET application was built and maintained by accenture, who can just as easily hire cheap devs in india or sri lanka as any other outsourced IT consultancy.
Also, they specifically state multiple times that the .NET solution would not scale to meet their needs, the quoted stats are 2.7ms/transaction in .NET and the linux app performs the same transaction in .4ms... So the linux system can handle 6-7 times the transactions on the same hardware...
They are talking about scaling up from 100 million transactions a day to 5-6 billion, so, yeah having to buy 6 times less hardware will probably save them some cash.
If you had read the earlier articles on the TradElect fiasco, you would have known that it was basically written and designed by Microsoft itself. Accenture had a very heavy involvement in the project straight from Redmond.
So yes, this is an outright condemnation of the quality of Microsoft's products.
Mart
"I know I will be modded down for this": where's the option '-1, Asking for it'?
"Enterprise wins for GNU/Linux don't come much better than this." Enterprise wins like this are happening all the time for Linux and other free software options. What makes this unique is MS touted LSE running their system as a huge win for their solution. The fact it gets ripped out a year latter for Linux is marketing gold if free software needed to market.
They had $60M to throw into development. There's a good chance it's as fast as they could make it.
Also, Microsoft gets to crow about the awesome power of their platform when they "win" these big installations. It's only fair we get to revel in it when they stub their toe on them.
Help stamp out iliturcy.
You are incorrect, they are trading a $65 million dollar piece of software for a $30 million COMPANY. They bought the MilleniumIT company that had ALREADY IMPLEMENTED a trading platform. They bought the company for the platform, and now they control the development of the platform going forward in house. They are not trading one IT consultancy for another, as they now OWN the software and the company that built it.
However, they state the platform they bought ALREADY achieves 6 times the performance of the piece of software built by accenture (.4ms vs 2.7ms transaction times).
While I agree that this is more of an indictment of Accenture's apparently shoddy work than of .NET itself, the fact that they've had 6 years (the article states the TradElect software/project was started in 2003) and $65 million dollars thrown at the problem and haven't been able to make the software perform better does raise some eyebrows about the underlying technology as well.
Uhh... I've never seen this level of RTFA and.. man this is slashdot where that is the norm.
the LSE ALREADY ENTERED A PURCHASE AGREEMENT TO BUY THE COMPANY that ALREADY BUILT A TRADING PLATFORM THAT IS BEING USED TODAY IN OTHER EXCHANGES! The deal closes in the next week or 2. The article says 95% of the "Non-Refundable" parts of the deal have already been transacted. Neither the LSE nor Millenium IT (the Sri Lankan company that is being purchased) is walking away from this deal.
You don't spend $30 million dollars and purchase a company if you aren't moving your software to that platform. The article states they already had a trial phase and brought in originally 20 platforms, shortlisted 4, ran those for a period, and MilleniumIT won. They then decided to purchase the entire company. This process is much further along the road than you seem to think.
You are not accurate. The LSE bought a dev shop that ALREADY BUILT A TRADING PLATFORM, that is being used today in other exchanges. The platform in question ALREADY achieves 6 times the performance of their existing platform (built by accenture), and has MORE FEATURES.
And they are moving from an outsourced dev model to an in house model, as they now own the devs and the software. Sure they devs are still in Sri Lanka, but Accenture could just as easily hire people in India or Sri Lanka to get the same cost savings.
If you're over 300 kilometers away from the server, a one-way transaction will take more than 1 millisecond at the speed of light anyway. If millisecond gaps were that important, you'd hear about global disparities directly related to distances from the stock exchange servers.
Typical PHB and incompetent/ expensive consulting services debacle. See below for an older ComputerWorld blog entry.
_______________________________________
July 1, 2009
.NET
programs, which was created by Microsoft and Accenture, the global
consulting firm. On the back-end, it relied on Microsoft SQL Server
2000. Its goal was to maintain sub-ten millisecond response times,
real-time system speeds, for stock trades.
Steven J. Vaughan-Nichols
London Stock Exchange to abandon failed Windows platform
Anyone who was ever fool enough to believe that Microsoft software was good enough to be used for a mission-critical operation had their face slapped this September when the LSE (London Stock Exchange)'s Windows-based TradElect system brought the market to a standstill for almost an entire day. While the LSE denied that the collapse was TradElect's fault, they also refused to explain what the problem really wa. Sources at the LSE tell me to this day that the problem was with TradElect.
Since then, the CEO that brought TradElect to the LSE, Clara Furse, has left without saying why she was leaving. Sources in the City-London's equivalent of New York City's Wall Street--tell me that TradElect's failure was the final straw for her tenure. The new CEO, Xavier Rolet, is reported to have immediately decided to put an end to TradElect.
TradElect runs on HP ProLiant servers running, in turn, Windows Server 2003. The TradElect software itself is a custom blend of C# and
It never, ever came close to achieving these performance goals. Worse still, the LSE's competition, such as its main rival Chi-X with its MarketPrizm trading platform software, was able to deliver that level of performance and in general it was running rings about TradElect. Three guesses what MarketPrizm runs on and the first two don't count. The answer is Linux.
It's not often that you see a major company dump its infrastructure software the way the LSE is about to do. But, then, it's not often you see enterprise software fail quite so badly and publicly as was the case with the LSE. I can only wonder how many other Windows enterprise software failures are kept hidden away within IT departments by companies unwilling to reveal just how foolish their decisions to rely on archaic, cranky Windows software solutions have proven to be.
I'm sure the LSE management couldn't tell Linux from Windows without a techie at hand. They can tell, however, when their business comes to a complete stop in front of the entire world.
So, might I suggest to the LSE that they consider Linux as the foundation for their next stock software infrastructure? After all, besides working well for Chi-X, Linux seems to be doing quite nicely for the CME (Chicago Mercantile Exchange), the NYSE (New York Stock Exchange), etc., etc.
_______________________________________
I bet they will use Mono to ease the transition. If they've already got a huge codebase written for .NET, wouldn't it be insane to throw it away?
They don't like the performance, or the feature set of the current codebase. They are buying an entirely new system to address those issues. It would be far more insane to keep any of it, or have to maintain it - they want it out wholesale.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
SEC Proposes Ban on Allowing Stock Flash Orders (dated September 19th 2009)
Flash traders have direct connections to the NYSE exchange and pay large sums just for bandwidth to make sure the trades are almost real time. Goldman Sachs is a key participator in this.
That said, their trades often have no human interaction and generally are computers following trading algorithms only a block away from the exchange with a direct fiber line to the office. It would be impossible otherwise.
Some traders have been raising a stink over this, but generally the miliseconds do count.
From http://seekingalpha.com/article/150397-flash-trading-goldman-sachs-front-running-everyone-else
Of course I don't know how the LSE handles flash trading or even wants it but I'm going to assume they need everything to be as real time as possible. You just don't hear the finacial firms complaining about the disparities simply because they have the money to set up the transactions their servers pretty much next to the exchange itself (if not in the same building).
"I am the king of the Romans, and am superior to rules of grammar!"
-Sigismund, Holy Roman Emperor (1368-1437)
A generic list, even if it is array based, is going to be on the stack an array of pointers to other points of the stack and the heap.
If you use STL, then std::vector will also allocate its backing store array on heap.
On the other hand, if you use C#, you can use stackalloc to get a stack-allocated, non-GC-tracked array.
Managed .NET arrays (not stackalloc or unmanaged heap allocated) will still be slower because there are bound checks for element access (though JIT can eliminate them sometimes when it sees that they can never fail).
Mutable generic collection classes are even more slow, because they also have safeguards to do things like throwing an exception if you get an enumerator for a collection, then remove an item from that collection, and then try to move the enumerator (whereas in C++, doing same thing for a vector would just render all active iterators invalid, and their use would lead to a crash at best, and silent data corruption at worst). This is achieved by storing a "version number" for a collection (just as plain int) which incremented it on every insertion/removal - and which enumerators check against every time you move them. Naturally, this increment happening on every insert also slows things down.
From now on, it will no longer possible to take refuge in the idea that you can't get fired for keeping with Microsoft.
the CEO that brought TradElect to the LSE, Clara Furse, has
left without saying why she was leaving. Sources in the City-London's
equivalent of New York City's Wall Street--tell me that TradElect's
failure was the final straw for her tenure.
So, when Microsoft makes so much noise with press adverts & getthefacts campaigns, its 'marketing' and when FOSS supporters rejoice they are 'fanatics'!! Just STFU and get back to your windows 7 house party.
1) Your programs don't even do the same thing since some of them have multiple increments of the loop variable.
2) Your C++ program is not idiomatic STL. If it were you'd use an iterator (which is typically a pointer for vector) as the loop variable.
I'm not of the opinion that insert-high-level-language-with-GC-here is necessarily slower than insert-C-or-C++-or-whatever-here, but bullshit benchmarks aren't going to help make that case.
the right tool for the job? .NET is fantastic for many different things. In fact, I have written high end video encoder systems in .NET that performed all real time and file based management for multiple 1.5gbps streams in .NET. However for the high demand code, I used C++ and even a few lines of assembly (I can't resist it, just have to write them, helps me sleep at night).
.NET is ENTIRELY! possible and even practical. Unfortunately, in a company like Microsoft, the developer with the skill set for such a job will almost always end up on development teams for Windows, .Net itself, Visual Studio, even Office. The developers left over to write database programs for customers will be of a much lower grade. Besides, there are very few good real-time systems developers that would choose to work on a database program rather than on something more interesting, like... I don't know... shaving toe nails for old ladies. Really, database programming is what people do when they can't do anything else, it's the data-entry job of programmers.
.NET will make NO difference at this level. The flaw at this point was poorly coded SQL. After all, by distributing the load of the web traffic across 500 blade servers, there was little chance that the .NET program they were running was the problem.
Developing high performance systems using
Sometimes Java is still a modern VM environment. CLR generally IS NOT. It has some features you would consider a VM runtime system, but if anything, those features improve performance over straight out compiling the MSIL code. Ideally, it would allow trace metrics to be calculated and where branches can be predicted, long traces can be compiled without cache-misses and penalties... creating MUCH higher performance code.
As for GC. Well, unless you can develop a system that eliminates memory allocation altogether and uses no threading while doing it. Good GC based environments (like CLR/Mono) are almost always faster than straight memory allocation. I highly recommend you research it... and if you're going to try and prove it with 5 lines of code, don't waste your time. That's not a real world test. Test it instead for example with an XML parser that generates a DOM tree and then deletes/dereferences it.
As a religious non-Java programmer and a devout Java basher, I'll shoot down the "Not suitable for nuclear reactors" thing. Java is 100 times more suitable for a nuclear reactor in most cases than C or C++ since the "object model" you would use in a Java program would centralize most critical bugs to a few lines of code that can be fixed to repair the whole program instead of spending months on diddling all the little memory and pointer related bugs you're likely to encounter. Also, for applications that are heavy allocators, relocatable memory in a Java environment can cause a system written by an "average programmer" to run much longer without crashing because of one memory abuse situation or another. Almost no "average programmers" even know where to begin to deal with memory fragmentation issues, yet they DO cause tons of problems.
In the case of this trading system, it's obvious Microsoft tried throwing hardware at the problem. That was all fine and good. Hell, add 500 more web servers and use 5 over those 32 physical Xeon processor machines from Unisys to drive the database.
Instead, it's FAR more likely that abuse of the database was the real problem. Most database front ends querying data from SQL servers are written by mediocre database UI developers that have no respect for what the SQL server might actually have to do in order to process their queries. On top of that, they like to do things like create tons of views and indexes that all need to be updated constantly. Queries get SLOWED down and it doesn't matter how fast the application is, the SQL server can't keep up with the crap code on the back end.
So, while you are bla