Mike
--- On Tue, 2/8/11, Whitney <whitne...@gmail.com> wrote:
____________________________________________________________________________________
The fish are biting.
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php
I've been planning to do something a little different than a pure AmiBroker implementation. I'm approaching an alpha release of a distributed backtester/optimizer/walk forward analysis framework.
At the moment the product is a desktop application that spawns multiple instances of a trading engine across multiple cores of one or more machines on a LAN, capturing all results in a database. Once the desktop version is shipping, I'm seriously considering releasing a cloud edition hosted on the web for on-demand use.
The application design is entirely modular and should allow supporting any trading engine that can be programatically controlled. Similarly, it allows for integrating 3rd party optimizers, including something like leverage space.
Currently I've only implemented the integration for AmiBroker and AmiBroker's optimizers. However, I definitely plan to provide a leverage space optimizer. Any optimizer written using the AmiBroker SDK will work in my environment "out of the box", though it will not take full advantage of the parallelization that I offer unless making a slight change to return multiple combinations in a single request, as opposed to a single combination per request. In the case of the CMA-ES optimizer this was easily done, required no API change, and remains 100% backwards compatible with AmiBroker (i.e. revised DLL can still be used in both AmiBroker and my product).
Where it may not be of help to you is that I plan to write the leverage space optimizer in Java instead of C++, so it won't be available as a DLL to AmiBroker. My motivation for that is not to deny AmiBroker users, nor to force anyone into my own product, but rather simply because I haven't worked in C++ for 15 years and don't have any interest in going back to it. I'm waaaaay more productive in Java and don't want to waste time getting up to speed again in another language, development tool, etc.
Mike
--- On Wed, 2/9/11, Whitney <whitne...@gmail.com> wrote:
# Code
require(LSPM)
data(port)
require(snow)
cl <- makeSOCKcluster(2)
### Short horizon
system.time(for(i in 1:1e3) probDrawdown(port, 0.1, 3, error=1e-9))
# user system elapsed
# 0.62 0.00 0.63
system.time(for(i in 1:1e3) probDrawdown(port, 0.1, 3, error=1e-9, snow=cl))
# user system elapsed
# 0.89 0.05 1.47
### Long horizon
system.time(probDrawdown(port, 0.1, 7, error=1e-9))
# user system elapsed
# 30.94 0.00 31.00
system.time(probDrawdown(port, 0.1, 7, error=1e-9, snow=cl))
# user system elapsed
# 0.00 0.00 15.59
stopCluster(cl)
# End Code
The short horizon example takes longer with snow because it takes time
to send data to/from the nodes to the master process. The nodes spend
most of their time waiting (as evidenced by the massive traffic on the
loopback interface on my *nix machine). The long horizon example is
faster because each node spends the majority of the time pegging the
dual-core CPU at 50%.
Best,
--
Joshua Ulrich | FOSS Trading: www.fosstrading.com