|
PureBytes Links
Trading Reference Links
|
Hello Tomasz,
Thanks for all you've done with AmiBroker. It is a great program. In
your response to your dual-core optimization comments, there's
something I've been wondering about. You said that the core cache
becomes a limitation for AFL because backtesting is so memory
intensive and the memory interface speed is fixed no matter the number
of cores on a processor.
Currently, if I do an Optimization over a large watchlist, AB will run
the AFL with the given parameters for the entire watchlist all the way
until it has the overall system result for the entire watchlist, for
the given parameters. Then it alters the parameters according to the
Optimization and reruns the AFL for the entire watchlist again. This
continues for all the Optimization iterations.
As I understand you, the problem with this is that the data for the
watchlist takes up a lot more memory than will fit in a core's cache,
so if you have multiple cores doing this processing simultaneously,
they will be fighting each other for memory bandwidth.
Would it be possible to alter the order of events? If I'm running an
Optimization with 100 combinations I don't need to see the results
from each combination until the entire set has been processed. What if
the Optimization sequence of events was changed to run the AFL for
just one symbol from the watchlist, then alter the parameters and run
the AFL again for the *same symbol*, just with different parameters,
and continue this for all the combinations of the Optimization. After
signals have been generated for this particular symbol for all
parameter combinations, the signals can be stored in memory and then
it can move on to the next symbol. After all the symbols have been
processed, AB can do the backtesting for all the signals.
The advantage of this is if I am Optimizing 100 combinations of
parameters on a watchlist of 5000 symbols, hopefully 1 symbol can fit
in the processor's cache and it can do 100 runs through the AFL,
generating signals, before it has to fetch more data from the memory.
This could provide some concurrency as another core could do the same
thing for a different symbol. The Optimization would be more efficient
with more combinations.
Does this make sense? I know that I glossed over details of how the
cache really works and also that I do not know the internals of
AmiBroker and could be missing some critical information and therefore
this idea may not work at all. But maybe it could help. Thanks for
listening!
Nick
--- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <groups@xxx> wrote:
>
> Hello,
>
> It is perfectly valid question.
>
> First it does not really matter if the process goes through both ends or
> sequentially but one core goes though odd and another through even
steps,
> and at first look it seems like this would give significant speed up.
>
> BUT... in real world things are more ugly that in theory.
> I did lots of testing and profiling (measuring time of execution of
code on function-level),
> and dual thread execution on dual core processor is faster if and
only if
> each core can execute accessing data only from its own on-chip data
cache.
> This is unfortunatelly NOT the case for backtesting/optimization.
> On-chip caches are usually limited to well below 1MB. Almost every
backtest
> requires way more than 1MB.
> Now what happens if you run code that uses more memory -
> BOTH cores need to access on-board (regular) RAM. Both cores do this
> through single memory interface that is SHARED between cores and
> access one memory that runs at fixed speed (no matter if 1 or 8
cores access
> the memory - it can not respond quicker than factory limit and one
core is
> fast enough to actually need to WAIT for memory).
>
> Now if you run on 2 or more cores, they have to wait for the same,
single shared memory
> that runs at constant pace, slow enough for one core, not to mention
more.
>
> Net result is that if you actually try to run something that needs
more than 1MB
> of data and does not fit into individual data cache, the performance
drops down
> to actually single-core. What's more it can run slower because of
additional overhead with
> thread management.
>
> And it is not imagination or theory. I did actual code profiling and
I was surprised to when I tested multi-threaded
> code. It works upto 2x faster, on dual core BUT ONLY IF you don't
access more than
> the size of on-chip per-core data cache. Or your code needs way more
calculation than memory access.
> If your code does a LOT of memory access (more than 1MB) and does it
QUICKLY
> (backtesting is extremely memory intensive and AFL scans through mem
like crazy)
> all advantages of running in multiple cores are gone.
>
> BTW: what I did in this upgrade to speed up the
backtest/optimization was to reduce the COUNT
> of memory accesses to absolute minimum required. As it turns out
even single CPU core was waiting for memory.
>
> Best regards,
> Tomasz Janeczko
> amibroker.com
> ----- Original Message -----
> From: "tipequity" <tagroups@xxx>
> To: <amibroker@xxxxxxxxxxxxxxx>
> Sent: Friday, October 05, 2007 4:20 AM
> Subject: [amibroker] Re: Optimization speed increase in 5.01
>
>
> > Tomasz, at the risk of sounding stupid, I am gonna run this idea by
> > you. Since AB during backtest and optimizations work on a list of
> > stocks why not have one cpu (dual core CPUs) work on symbols from top
> > of the list and another cpu to work on symbols from the bottom of the
> > list. Like buring candles from both end.
> >
> > Regards
> >
> > Kam
> >
> >
> > --- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <groups@>
> > wrote:
> >>
> >> Hello,
> >>
> >> If you are running optimizations using new version I would love to
> > hear about the timings you get
> >> compared with old one.
> >> Note that optimization with new version may run even 2 times faster
> > (or more),
> >> but actual speed increase depends how complex the formula is and
> > how often system
> >> trades and how large baskets. Speed increases are larger with
> > simpler formulas,
> >> because AFL execution speed did NOT change. The only things that
> > has changed
> >> is collection of signals (1st backtest phase) and entire 2nd phase
> > of backtest.
> >> As it turns out, when backtesting very simple formulas the AFL code
> > execution is only less
> >> than 20% of total time, the rest is collecting signals and sorting
> > them
> >> according to score and 2nd phase of the backtest (actual trading
> > simulation).
> >> These latter areas were the subject of performance tweaking.
> >>
> >> Best regards,
> >> Tomasz Janeczko
> >> amibroker.com
> >>
> >
> >
> >
> >
> > Please note that this group is for discussion between users only.
> >
> > To get support from AmiBroker please send an e-mail directly to
> > SUPPORT {at} amibroker.com
> >
> > For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> > http://www.amibroker.com/devlog/
> >
> > For other support material please check also:
> > http://www.amibroker.com/support.html
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
>
Please note that this group is for discussion between users only.
To get support from AmiBroker please send an e-mail directly to
SUPPORT {at} amibroker.com
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
For other support material please check also:
http://www.amibroker.com/support.html
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/amibroker/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/amibroker/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:amibroker-digest@xxxxxxxxxxxxxxx
mailto:amibroker-fullfeatured@xxxxxxxxxxxxxxx
<*> To unsubscribe from this group, send an email to:
amibroker-unsubscribe@xxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|