Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
Please consider creating a thread on futures.io (formerly BMT) to document the high level process. Several people on futures.io (formerly BMT) are doing similar projects and it would be of benefit to everyone.
Oh my, I don't even know where to start with showing how to develop an institutional standard trading application for live trading, there's so much to talk about, so many layers to try and abstract from, it would take several books and a huge huge video blog on it!
What I can say is that I am willing to share a beta version of my application here on futures.io (formerly BMT) freely so that trading system builders who are frustrated with the limitations of the current offerings of NT, TradeStation, MultiCharts can test out strategies and optimize strategies without any of the speed limitations of bad software design.
I think this will be more helpful and to the point for everyone here on futures.io (formerly BMT)?
Bad design = bad performance. Thus the necessity to have the knowledge and experience to implement good architecture, using best patterns and practices becomes quintessential in developing reliable and scalable applications.
SOLID design principles are often forgotten in RAD (Rapid Application Development), meaning things like loose coupling, DI, IoC's and Service Location are not implemented when trying to push the next application through the door too quickly to grab your hard earned money, and these are some of the main core concepts of a well designed application.
Regarding multi-core and threading, it's an issue of using the correct data structure and handling of the thread pool. In fact with C# 5.0, handling worker threads directly are no longer required, we can now use Tasks, a higher level abstraction which is part of the TPL (Task Parallel Library) and it's main job is to handle the life span of threads in the thread pool.
Some data structures such as the "blocking collection" handles the access to an object collection much more efficiently and safely than the old "lock" object could. Again, it is the ability to use the correct implementation of the right data type at the right time that will make or break the performance of an application here.
Also, like I have pointed out previously, functional languages such as F#, which is fully operable with C# and other .NET languages allows for the speed performances that is insanely off the charts! F# was built for performance and there are many examples of code block implementations done in F# that for the same result or functionality in C# makes C# feels like it was built in the stone ages!
So no, multi-core isn't the be all and end all, however, it is the correct implementation and knowledge to leverage the performance increase by good architecture design using a multi-core processor.
And everybody will still forget the fact that in large OO projects the cores are stalled anyway waiting on various on-chip, off-chip and motherboard memory caches...
