[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[amibroker] Re: Another side to the multi-core support argument



PureBytes Links

Trading Reference Links

Sorry, I used the term 'symmetric processing' incorrectly (I now see 
that it has a formal definition whereas I used it informally).

What I meant was that I don't think software applications for MCP are 
limited only to single tasks where a sequence of code lends itself to 
being chopped up, shoved through the processor and put back together 
again on the other side.

Couldn't software modularise its tasks/features and present them to 
the OS as if they are separate programs e.g. downloading RT data, in 
AB, and saving to a local database, could be allocated one core, by 
the OS, and rendering that data into a chart/processing indicators 
allocated to another - possibly AB could use some smart 
prioritisation of its own tasks and work in tandem with the OS to 
prioritise access to core CPU's?

It seems to me we are limiting ourselves with regard to the 
possibilities.

(I haven't read, or tried, Freds MCO stuff - maybe that is what he 
did there already, in a basic way).

If and when AB goes ahead with multicore application I have to wonder 
why anyone wouldn't want to upgrade - could that be the time to end 
the unlimited backward compatibility rule (the benefits of 
maintaining backward compatibility for a few would no longer be worth 
the effort and even detrimental to the many)?

brian_z



--- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@xxx> wrote:
>
> Re: what can traders do with multicore processing (MCP)?.
> 
> Gee, where are all the Codesters when you need one?
> 
> Are you guys holding out on us?
> 
> MCP applications aren't limited to symmetric processing are they?
> 
> http://en.wikipedia.org/wiki/Computer_multitasking
> 
> http://en.wikipedia.org/wiki/Multi-core
> 
> "The amount of performance gained by the use of a multicore 
processor 
> depends on the problem being solved and the algorithms used, as 
well 
> as their implementation in software (Amdahl's law). For so-
> called "embarrassingly parallel" problems, a dual-core processor 
with 
> two cores at 2GHz may perform very nearly as fast as a single core 
of 
> 4GHz.[1] Other problems though may not yield so much speedup. This 
> all assumes however that the software has been designed to take 
> advantage of available parallelism. If it hasn't, there will not be 
> any speedup at all. However, the processor will multitask better 
> since it can run two programs at once, one on each core."
> 
> 
> To what extent does it depend on the hardware/OS e.g. are the 
> possibilties for AB different on a MSFT system with an AMD chip 
> compared to another OS with a different chip - if so how would AB 
> handle that across a wide range of users - it seems to me the AB 
> solution will have to be generic rather than specialist?
> 
> 
> As a layperson, it appears that multi-tasking is a more exciting 
> prospect, for the majority of traders, than optimising at warp 
speeds.
> 
> Can't muliple processors handle multi-tasking at speeds unheard of 
> before and hence bring some things into the realm of possibilities?
> 
> 
> How about:
> 
> a) different databases running in one instance of AB - maybe even 
> with the databases in different timeframes/formats/coming from 
> different providers and being cross referenced in indicators.
> 
> Can MCP allow users,who now run more than one installation of AB on 
a 
> single computer (for whatever reason) to get the same results from 
> one installation. 
> 
> 
> b) in the past Tomasz would enable AB's native database for extra 
> data (historical fields other than OHLCVOI) - as I understand it 
> because it would weigh AB down with things not used by the majority.
> 
> Perhaps MCP will make the weight of an open structure AB database a 
> featherweight (PremiumData has already expressed an interest in 
> synching their database with AB so it is not as if there is no 
demand 
> for this feature).
> 
> c) a task scheduler built into AB - set the tasks at the start of 
the 
> day - if the keyboard/processor is idle AB starts to run the tasks 
> (backtesting/optimising).
> 
> d) if we want to run our trading platform and AB on real time with 
> two monitors on one computer do we have enough grunt to do that now 
> OR would MCP allow us to run processing intensive tasks like that 
> concurrently OR maybe with a minimised AB chart (on tick data) 
> floating on top of our trading platform window.
> 
> I don't know - I am merely speculating!
> 
> Surely someone out there has some better ideas?
> 
> brian_z
> 
> 
> 
> 
> 
> 
> 
> --- In amibroker@xxxxxxxxxxxxxxx, "sidhartha70" <sidhartha70@> 
> wrote:
> >
> > Hi Tomasz,
> > 
> > I've been reading the arguments for and against multi-core support
> > with interest, and I just wanted to add my own voice to it and 
> mention
> > an angle which hasn't currently been focused on.
> > 
> > Since I bought AmiBroker a couple of months back I've been blown 
> away
> > by not only what a great piece of software it is, but also by it's
> > value and the fantastic customer support. Your own responsiveness 
to
> > customer needs and ability to efficiently add new features leaves 
me
> > with no hesitations in recommending AmiBroker to my fellow 
traders.
> > 
> > However, I use AB in two ways. First for swing trading... for 
which 
> it
> > is not only awesome, but also works perfectly happily on one core
> > because of the lower overhead in terms of data through put and
> > therefore calculation overhead on that data.
> > 
> > I also use AB for higher frequency day trading... and it's here 
for 
> me
> > that multi-core support could really add something. For obvious
> > reasons the multi-core argument has so far been almost exclusively
> > focused on optimization. However, for higher frequency traders 
like
> > myself, working off just one core can be a significant bottleneck.
> > 
> > I have an IQ Feed 'tick' database... and some quite complex chart
> > setup's & indictaors. Currently, with chart refresh interval set 
to 
> 2
> > seconds (I'd like it quikcer) I can see one core of my computer
> > working away at about 50%. However, if I increase the update 
> interval
> > to zero to bring in every tick, I see useage on one core go up to
> > 80-90%. At this point, you can imagine, AB becomes noticeably 
clunky
> > and difficult to use. Things get even worse if I start to think 
> about
> > symbol linking. (for reference I am only looking at a couple of e-
> mini
> > symbols)
> > The frustrating aspect is that I have another 7 x 3Ghz cores 
sitting
> > there twiddling their fingers while AB is grinding up on one core.
> > 
> > So, I do think, for those of us who use AB for higher frequncy
> > trading, there is a very good argument to consider adding multi-
core
> > support outside of the optimization argument.
> > 
> > Love to hear your (or anyone's!) thoughts on this.
> > 
> > Many Thanks
> >
>



------------------------------------

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/