NYC Developers

B

bassman71

Hello,

I'm looking to implement my strategy, based in VB/Excel, into a more system intense structure, presumably using C++. The piece of the puzzle that seems daunting is recreating the bar strategy. I've been told that if the ticker list is low(which it is), keep it RAM based- which I don't exactly understand.

If you are or know of developers with expertise in this area, please contact me.

Thanks........Rich O
 
The advantage of keeping the market data memory based is that it allows you to analyze each ticker faster than would be able if you had your data stored onto your harddisk. This would also presumably speed up execution speeds because it reduces the delay for signal generation. The limitation to this is of course the size of memory you have, which is why it is only possible with a small ticker list.

Regarding moving your strategy from VB/Excel to C++, you are probably likely to require a much more complex/robust program since you wont have Excel's spreadsheet integrated with it. I don't know a lot about how strategies designed in VB/Excel work on a programming level; I am currently designing my system in C++. Hope this helps!

-- Paccc


Quote from bassman71:

Hello,

I'm looking to implement my strategy, based in VB/Excel, into a more system intense structure, presumably using C++. The piece of the puzzle that seems daunting is recreating the bar strategy. I've been told that if the ticker list is low(which it is), keep it RAM based- which I don't exactly understand.

If you are or know of developers with expertise in this area, please contact me.

Thanks........Rich O
More...
 
Quote from Paccc:

...The limitation to this is of course the size of memory you have, which is why it is only possible with a small ticker list.
...
-- Paccc
More...

I thought modern OSes (e.g., Windows) handle memory in a virtual manner. One can allocate a chunk of memory that's way bigger than the physical available memory.

:confused:
 
Quote from newfool:

I thought modern OSes (e.g., Windows) handle memory in a virtual manner. One can allocate a chunk of memory that's way bigger than the physical available memory.

:confused:
More...

You can...but it will make your system perform like a 386 2 MHZ machine. If you're really having memory problems just throw more hardware at it. At $100 per GB of memory there's no excuse for not having 2-3 GB if you need it for a trading system.

SSB
 
Quote from ExxTrader:

Need developers? Don't want to pay? Check out it4ex.com They build funds from the bottom up.
More...

I am sorry, but I have been with some of the firms mentioned in the flash-presentation for IT4ex (including as head of tech for one), but I have never heard of your firm. The presentation makes some confusing and misleading cleaims, like being a "vendor" for SFTI, you mean you are a SFTI customer, or a "vendor" for the ECNs, you mean you can route to the ECNs, like wise "vendors" for the prime brokerage.

If you are a broker (exxq.com, but I have no idea which firm EXXQ really is, if it is a member of any of the exchanges?), then say so. Do not spam a decent question with your thinly disguised advertisement.
 
Thanks for the insights. I am considering using MySQL and writing a .dll that links with the Genesis API. I'm sure this will be a more robust alternative to Excel(obviously). My strategy, although intraday, doesn't normally look to make quick round trips and as such a RAM based solution is not crucial.

Any advise/concerns with MySQL for evaluating data feeds.

RO
 
how come for quick round trips ram is not important ?

well maybe you mean you won't have to track many positions ?

even so, you need enough ram to make sure Windows is not swapping to disk (which is way slower than RAM) and will make your quick round trips, a little longer ..
 
What and or who are you looking to use for data feeds? Most of the providers totally suck now.... Bandwidth requirements are making most them cache with delays... Just wondering what you might be using I have been through a few and can be of some help finding you a good supplier.
 
Your best bet may be a combination of technologies.

You could continue to use MS-Excel as your front-end. This would give you ease of modification where a user needs it most.

For the grunt work, you could used a compiled language such as VC++ or VB and link it to your Excel app. The Excel app would then be able to call the functions from your compiled app.

This would also allow you to have things running in multiple threads, taking the best advantage of the CPU. You could have a "bar building" engine that would build your minute bars and not interfere with the main working of your Excel app. When you need that data, you just make a call from Excel VBA. Let the compiled app keep the most important/urgent data in memory, ready for when you call it from Excel.

I don't know how much speed your app requires, but you could also set up a RAM disk for your database. Key here is to make sure you have enough physical RAM. THe benefit of the bar building engine is that once a bar is built, the tick data can be dumped from RAM into a disk-based database. That provides you with the best use of RAM.

Cash
 
You must log in or register to reply here.
Back
Top