|
PureBytes Links
Trading Reference Links
|
Some fantastic well measured points Brian.
Lots of things I've thought, but couldn't put so eloquently into so few words.
>- they are well informed about performance issues and typically limit indicator code and symbols traded as a trade off to gain CPU time to drive their 'trading platform' processes.
>- it might not ever be practical for the majority of traders to trade
microevents OR trade them via AB .... however, like AB/Tomasz, I want to gather some evidence from real world testing, to find out for myself, and not rely on others beliefs about whether it is viable or not.
Yes, let the end user decide what they can or cannot do in regards to data storage and performance.
>- in any case, leaving aside the issues of collecting/managing the extreme amount of bid/ask data generated in a single days trading and assuming that testing has been managed somehow and that I have a valid bid/ask system I want to implement.
I've just recently started saving Time & Sales data for processing as I want to display buy vs sell trades. Here's some of my analysis to put the type of processing required into context.
I trade the SPI, which is admittedly not a heavy instrument compared to the US indexes. The heaviest day I've had so far is ~30,000 contracts volume.
This breaks down in Time & Sales to: (All values are rough rounded)
- 42000 records, of which there were
- 15000 individual trades
- 14000 bids
- 13000 offers
The file size for this is only 1.23mb and all days so far show roughly the same ratio of bid/ask records to trade records. 2:1. Curiously, nearly 10k of the 15k trades were single contract ones.
I wrote a Java app to process this data. It takes about 60ms to read the entire file, and about 400ms on top to process all 42000 records (number conversions, logic etc).
I have a p4 3.2ghz (slow by current standards).
In reality, you only need to process the most recent records since the last update, maybe a few hundred or thousand depending on how much time you allow between updates.
As you can see, it's not a lot of data (1.23mb) to begin with and processing this many records is of no concern at all. Even several hundred thousand records would not be an issue to progressively process.
I plan to run this alongside AB and read the Time & Sales in realtime if Tomasz is kind enough to implement my logging request. This will take up practically zero cpu time. The java app compresses the data into useful format so I can read it back into AB and display it.
Alternatively, it can be created as a C++ plugin in AB which would be way faster all around as the data can be written directly into static vars.
>- I would need the arrival of the a new bid/ask to be an actionable event ...down to the time limits of processing etc where execution would revert to minimum ontime basis if the number of bid/asks that arrive exceeds processing capabilities i.e. automatically execution of the bid/ask calcs would have to resort to a time absis in extreme high volume?
It'd have to be either one or the other Brian, not a switch between the two because you code differently for each of these models. If every tick event couldn't be guaranteed, then there'd be no point to this model, and you may as well use the time basis one in which AB currently operates.
In the tick event model, if you couldn't process the events quick enough, the queue would just get longer and longer, but you're still guaranteed to get every event.
>- I would have to forgo 'historical saving' of bid/ask data .. even data used on the fly might have to be progressively dumped as new data comes in (challenging to find ways to keep it all for the session if we want to do what if checks at the end of the day ... unless of course MCP somehow 'saves the day' in this regard).
This very much depends on how you use the data. For instance, the following chart:
http://www.tradingeducationexchange.com/products/images/ioamt/30min2.png
can be rendered from say 1000 variables which are updated from the incoming data. The raw data can then be discarded. You could call this a progressive update chart. It's like an mpeg movie, it doesn't load the entire thing into memory, but only requires as much as the current frame requires.
The other type is the traditional indicator chart or if you want to backtest the data which would require the entire array. The number of bid/ask records in this scenario could cause performance problems for realtime sampling.
In terms of total amount of data, as you could see from the Time & Sales analysis above, it's not much, but I guess it depends if you want to store that data for single futures instruments or for entire stock lists. Even the later is probably possible with today's hardware though.
>- should AB keep its focus on being a cutting edge BackTesting engine, with some secondary RT charting that is only intended to supplement design and testing efforts, and leave RT high frequency trading to other software?
To me, AB is already well suited to both, and I use it for realtime trading as I'm sure many others do. I've no doubt Tomasz will continue to plug the gaps over time as traders keep calling for them to be filled. The only other software package I've used is WealthLab, but not for tick data, so I don't where AB lacks in comparison to others in the realtime arena, but it's array processing speed still blows me away.
Regards,
Julian.
--- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@xxx> wrote:
>
> As always the ideas flow too fast for the typing/spellcheck/theasuraus etc to keep up with.
>
>
>
> Three ideas I left out of my previous post by mistake.
>
> idea #1) RT trading the spread:
>
> - assuming once again that I have somehow managed to backtest bid/ask scenarios (say that somehow AB finds a way to let me gather enough of this data on an historical basis ... not too much ... and also has the bid/ask, market depth fields that allow me to do the testing)
>
> - following BT I now I have a strategy that is valid i.e. every time the ask steps up a tick I go long etc.
>
> How to trade this in RT?
>
> - I no longer need to reference historical data
> - I only need to compare the last ask to the current ask (I am not trading short in this scenario so I don't need to reference the bids ... this saves on data handling and calcs etc ... unless of course my strategy demands that both the bid and the ask move up a tick)
>
>
> Am I necessarily concerned about every bid/ask (say, for arguments sake, that they are coming at 200 per sec)?
>
> The answer is no ..... because the ask changes faster than I can calcualate the move ---> then elect to go long ----> then place the order ----> etc I don't need to worry about what is happening to the ask after I receive a buy signal.
>
> After that, I don't need to worry about the ask again until I am out of the trade and need to go back in again i.e until my account is idle.
>
> So my logic, directed towards my RT software, is:
>
> ..... if out of a trade then ----> (watch the ask and don't do anything else anywhere else except report to the user that you are out of the trade)
> - when you get a buy signal then -----> (stop watching the bid/ask and initiate the trade cycle i.e. place order etc AND report to the user that the order is placed etc )
> - once order is accepted place a watch on the exit signal (this may or may not involve the bid or the ask)
> - and so on.
>
> In short:
>
> 1)I can trade the bid and the ask without always algorithmically watching the bid and the ask
> 2) I can receive 'visual' reports on my bid/ask trading even less often than the frequency of my algorithmic watching
> 3) I don't need to watch every bid/ask event ... any bid/ask buy signal will do the job .... since it takes me longer to action a trade than it does to record a bid/ask event I can stop bid/asks watching most of the time i.e. I only need to 'sample' a fraction of the available bid/ask events to trade bid/asks in RT.
> 4) When sampling the bid/ask this is a form of event programming/trading?
> 5) Other processes are necessarily stripped to the minimum requirememts and they have to wait for the all important event before getting a run?
>
>
>
> idea #2 Synchronized chart refresh:
>
> - if AB could allow user defined chart refresh How about synchronized refreshes
> - (assuming AB allows ms timestamping and we can then create real,s ay, 1/10th sec databases) .... if the database 'base' timeframe is 0.1 sec then default refresh rate is 0.1 sec .... users could then set other windows to refresh at a slower rate (as required) i.e. some windows would refresh every 2* base rate == every 0.2 secs OR say, every 10* base rate == every 1 sec and so on.
>
>
> --- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@> wrote:
> >
> > The intention of the mother thread,"Data and PlugIn Speed", was to focus on AB's RT Performance, as opposed to its capabilities as a Backtesting Engine.
> >
> > For me this was an educational post and IMO the discussion has progressed nicely, across threads, with contrasting emphasis on speculative ideas, on one hand, and hard-nosed critique, accompanied by factual observations, on the other ... it is quite OK with me if others see the topics in a different way. or pursue other objectives/sub-objectives within them.
> >
> > To me it was always just a discussion, and not intended to be specifically critical of AB, or Tomasz, while at the sametime being pertinent enough to have value.
> >
> > IMO opinion using the forum as a sounding board, which provides users with the opportunity to sound off, pool our factual evidence and make critical assessents, prior to filing formal suggestions, is the best model for introducing progressive ideas that we have.
> >
> > (As a rule of thumb, we need to sound off on them several times before they start to sound reasonable to the majority).
> >
> > Keep in mind that only a fraction of the discussion will end up as a formal suggestion and that only a small % of filed suggestions will ever be implemented (especially in their original format).
> >
> >
> >
> > Re RT Performance versus Backtesting Performance:
> >
> > Irrespective of what AB's BT can, or can not, do, the reality is, that for one reason or another, many of us do use it as dual software i.e. we do use AB as both a BT and trading platform software.
> >
> > Note that Janhaus said that he does not, and will not, use AB for high frequency trading, however, his objectives and situation (budget/ skills/hardware) are most likely unique compared to the AB user norm.
> >
> >
> > From the discussion, so far, it seems that RT users:
> >
> > - want a trading platform type window with different behaviour to the other windows
> > - use a dedicated machine for RT trading (or close all other programs while RT trading)
> > - if they want to run extras, while running AB in RT mode the preference would be for additional monitors (go MS, go!)
> > - use of machines with MCP's is standard (number of cores vary!) ... multicore is now standard for midrange off the shelf desktops?
> > - they are prepared to buy machines, use OS etc that are particularly suited to AB use
> > - consider that CPU useage is a critical issue ... consequently they want control over GDI workflow and CPU workflow
> > - they are well informed about performance issues and typically limit indicator code and symbols traded as a trade off to gain CPU time to drive their 'trading platform' processes.
> > - they are well informed about and want control over the amount of data processed i.e. they want execution flow control
> > - they don't want to have to reference AA ... this is seen as being irrelavent when RT trading (either they are correct or some intense education is required to change this view).
> >
> >
> > Speculating further, without any social or practical constraints in place (in order to learn some more or perhaps unearth some new issues or possibilities):
> >
> > - spread trading is the most extreme trading that we could consider (one person in this forum has already indicated that this is a strategy they are following, albeit not with AB as the software)
> > - bid/ask and tick arrival can be considered micro-events, compared to compressed data e.g sec or minute bars etc.
> > - microevents are dynamic, in time, and therefore need to be handled dynamically (indicators might need to be dynamic and not use any lookback data at all?)
> > - it isn't practical for me (at this stage) because MarketMarkets play the spread without any frictional costs and they are sitting on top of the markets with highspeed gear (compared to myself only)
> > - it might not ever be practical for the majority of traders to trade microevents OR trade them via AB .... however, like AB/Tomasz, I want to gather some evidence from real world testing, to find out for myself, and not rely on others beliefs about whether it is viable or not.
> >
> >
> > Hypothetically to BT bid/ask scenarios:
> >
> > - bid/ask data without volume at the bid ask is of lessor value therefore to Backtest some bid/ask indicators I will need a BT with fields/functions that accommodate bid/ask and volume at the bid/ask at the least (full market depth history would be required to fully test all possible strategies)
> > - possibly historical bid/ask data could be collected, by my software, when I am not actively enaged in RT trading OR perhaps I could buy some historical data OR alternatively I could rely on live paper trading, using only a small number of recent bid/asks etc and then only save the tradeSeries/calculated indicators for historical reference
> > - in any case, leaving aside the issues of collecting/managing the extreme amount of bid/ask data generated in a single days trading and assuming that testing has been managed somehow and that I have a valid bid/ask system I want to implement.
> >
> > (Perhaps that aspect requires a separate thread).
> >
> >
> >
> > Hypothetically for RT spread type trading:
> >
> > - I would need the arrival of the a new bid/ask to be an actionable event ... down to the time limits of processing etc where execution would revert to minimum ontime basis if the number of bid/asks that arrive exceeds processing capabilities i.e. automatically execution of the bid/ask calcs would have to resort to a time absis in extreme high volume?
> >
> > - I would not want to see every 'behind the scene' bid/ask calc (is it likely that the MarketMakers, who set the spread, are visually looking at every incoming bid/ask OR would they algorithmically make/take the bid/asks and only PHYSICALLY watch a summary of the process instead?) .... I assume that in order to play this game I could physically look at every event when looking at historical data in the BT but that for RT trading I would have to handover to my faster AT computer when in trading mode.
> >
> > - so, I would elect to AT the high frequency bid/ask indicators and only render actual trades entered, or orders placed etc, in a window that needs to be refreshed i.e. I would only physically watch timed reports on my key performance indicators /trouble shooting status etc.
> >
> >
> > Hypothetically .....what would I require of my software to be able to trade the spread:
> >
> >
> > (... thinking as a layperson ... first pass/draft version only)
> >
> >
> > - everything would have to be optimized to extreme levels to achieve this extreme performance
> > - I would need finer control of what constitutes an event e.g. arrival of a bid/ask or a tick is far more important than user action e.g scrolling, so new bid/ask or tick quotes would need to be recorded as an actionable event in the fastest possible way
> > - I would need bid/ask calculations threaded out (almost certainly to another core?) and worked in the background (no visual reporting of most of this)
> > - I would need a 'trading platform' type window, or windows, to provide me with the absolute bare min of updated reports from the algorithmic trading that is going on in the background
> >
> > (I would need the training and mindset to go with this style of trading .... it is just like the difference in flying a high performance aircraft, with only virtual feedback available, and flying a hobby aircraft by looking out the window).
> >
> > - I would have to forgo 'historical saving' of bid/ask data .. even data used on the fly might have to be progressively dumped as new data comes in (challenging to find ways to keep it all for the session if we want to do what if checks at the end of the day ... unless of course MCP somehow 'saves the day' in this regard).
> >
> > - I would need control over when a particular window refreshes and what drives the refresh e.g. refresh actions would need to be parameter driven .... by default all parameters would be included (as in AB at present) but the user would elect what refresh actions to turn off for any particular chart (all turned off,except for slow timed refresh would == something similar to commentary? ... it would just give us a, say, 10 sec update on the score == W/L, PayOffratio, open trades, net gain etc)...... in effect, a window with most actions/events disabled would function just like a static graphic (the keypoint is that users should be able to define this, or graduations of it, for themselves).
> >
> > - I would need fine grain/extreme control over how much data to process at any time/for any event.
> >
> >
> > Realistically:
> >
> > - can AB achieve this?
> > - is it desireable for AB to achieve this?
> > - should AB keep its focus on being a cutting edge BackTesting engine, with some secondary RT charting that is only intended to supplement design and testing efforts, and leave RT high frequency trading to other software?
> > - at the least, shouldn't AB allow us to somehow create an extreme event database and do our testing within AB ... and do this with off the shelf features, so that it is accessable to all?
> > - perhaps thinking about how AB could hyptothetically trade microevents, in RT, will lead to some realisitic options that will end up being implemented by AB, for use at subsecond timeframes (not necessarily bid/ask trading).
> >
> >
> >
> > KEYWORDS
> >
> > OPTIMAL RT PERFORMANCE
> >
> > --- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@> wrote:
> > >
> > > > I just believe you'll get better support for what you're asking >within the realm of tick by tick trading.
> > >
> > > I agree that the issue is best considered in the context of bid/ask OR tick trading ... hypothetically considering those propositions is where we can learn the most about where we are, where we would like to go and whether, or not, we can realisitically expect to get to any of those places (more on this in another post).
> > >
> > >
> > >
> > > > May be Tomasz will implement it as it is for you, best of luck.
> > >
> > > IMO the arguments put forward by Julian, and supported by Dennis and Yofa, are compelling i.e.
> > >
> > > it is not an issue of scaling up, via application of new MS GDI features but rather one of taking the load off the GDI by removing unnecessary graphic rendering from the queue (some people seemed to mis-read Julians suggestion and kept going back to the GDI multithreading argument ... bottlenecking at the GDI is the argument that makes Julians case, rather than breaks it!)
> > >
> > > The second compelling argument, made by the proactive group, is that threading out background tasks, calculations etc from graphic rendering tasks can lead to RT improvement.
> > >
> > > I accept this generic argument (in fact I naively guessed at it myself a way back at the MultiCoreProcessing discussions) .... what I am not sure about is how it could apply in specific cases e.g. on a particular machine, where machines can have different OS and cores OR within AB in general, where the priority of subtasks could be user defined.
> > >
> > > Against this you posted the third most telling point of the discussion so far (in the top three points somewhere) when you highlighted the fact that AB only stamps bars down to a resolution of 5 secs ... I agree all RT performance theorising etc stops at that point, like a car hitting a 10ft thick concrete wall.
> > >
> > > At the end of the day, only Tomasz can make structural changes while we are left with the power to chose from the cards we are holding in our hands.
> > >
> > > >BTW with a few lines of C/C++ using windows timer you can implement >your own suppressedrefresh function which will do exactly what you >want.
> > >
> > > Sounds like an idea worthy of further investigation.
> > > Probably a bridge to far for me at this stage ... maybe in a year or two.
> > > In the meantime the discussion on how to bring this to the people, via AB features, is a good one.
> > >
> > > Thanks for your good pragmatic contributions.
> > >
> > > --- In amibroker@xxxxxxxxxxxxxxx, "Paul Ho" <paul.tsho@> wrote:
> > > >
> > > > I just believe you'll get better support for what you're asking within the realm of tick by tick trading. May be Tomasz will implement it as it is for you, best of luck. BTW with a few lines of C/C++ using windows timer you can implement your own suppressedrefresh function which will do exactly what you want.
> > > >
> > > > --- In amibroker@xxxxxxxxxxxxxxx, "Julian" <juliangoodsell@> wrote:
> > > > >
> > > > > Yes, I partially agree with you Paul,
> > > > >
> > > > > however just because some traders might see a feature as unnecessary and can't see a use for it, doesn't make it so or mean there isn't one. GetRTData and automatic trade entries are an example where sub-second updates could be useful.
> > > > >
> > > > > The fact that Tomasz has actually implemented a per tick update option means it must have been useful to some, unless he did it for fun. :) The problem is simply that this resolution is not available via requestTimedRefresh.
> > > > >
> > > > > Whether this feature is only useful to a minority of traders or not, it's such a simple (supposedly) fix, for a feature that is already supported, but is hindered in practice.
> > > > >
> > > > > Regards,
> > > > > Julian.
> > > > >
> > > > > --- In amibroker@xxxxxxxxxxxxxxx, "Paul Ho" <paul.tsho@> wrote:
> > > > > >
> > > > > > As long as the restiction on the resolution of timestamping of price data is set at 5 sec. There is no point in trying to RT trade at tick level. As the requirement of unique time stamp is waived in storing tick data. tick database often gets corrupted, ie., later db records can have older time stamp. And together without knowing the exact timing of these ticks coming in. I dont believe there is anyone who is willing to trade with REAL MONEY at tick level.
> > > > > > From a practical standpoint, I have never found this refresh rate striction difficult to live with. A resolution of 1 second is plenty fast enough for me, even for trading futures.
> > > > > > I think Tomasz is thinking about rehashing the underlining db structure. Along with changing Volume to a floating point number. if he would consider expanding his PackDate to more than 4 bytes. He can then have a timestamp resolution of a fraction of a second. Then any request to enhance tick trading would make more sense. In the meantime. there isnt much point in trying to get a faster refresh rate than 1 second IMHO.
> > > > > >
> > > > > > amibroker@xxxxxxxxxxxxxxx, "Julian" <juliangoodsell@> wrote:
> > > > > > >
> > > > > > > Yes Paul,
> > > > > > >
> > > > > > > the crux is that requestTimedRefresh only has a 1 second resolution, whereas in the preferences you can set it to 0 for per tick updates, or as fast as your charts permit.
> > > > > > >
> > > > > > > What I'm requesting only applies to the instance where you have it set to 0 in the preferences.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Julian.
> > > > > > >
> > > > > > > --- In amibroker@xxxxxxxxxxxxxxx, "Paul Ho" <paul.tsho@> wrote:
> > > > > > > >
> > > > > > > > Julian
> > > > > > > > It does, but only if the refresh time interval is >= 10 seconds as well.
> > > > > > > > I do that all the time with my RT trading. I have trading logic that is updated every 1 sec, and querying and displaying of my positions as a separate chart, updating every 10 seconds.
> > > > > > > > If you put now() in your chart title, you can see how often your chart is being refreshed.
> > > > > > > >
> > > > > > > > --- In amibroker@xxxxxxxxxxxxxxx, "Julian" <juliangoodsell@> wrote:
> > > > > > > > >
> > > > > > > > > Paul,
> > > > > > > > >
> > > > > > > > > the problem with requestTimedRefresh is that it doesn't remove that chart from the standard update queue.
> > > > > > > > > If I specify requestTimedRefresh(10), that chart is still going to be updated along with every other chart on every standard refresh, perhaps once a second, which is a waste of cpu time.
> > > > > > > > >
> > > > > > > > > What I want is for that chart to only update every 10 seconds so that other charts can be updated more quickly.
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Julian.
> > > > > > > > >
> > > > > > > > > --- In amibroker@xxxxxxxxxxxxxxx, "Paul Ho" <paul.tsho@> wrote:
> > > > > > > > > >
> > > > > > > > > > I'm not sure what you're trying to do.
> > > > > > > > > > It is already possible to specify how often to update charts individually. The refresh rate in preference set the slowest rate and the default refresh rate. Individual chart can be refreshed at a rate set by requestTimedrefresh(). the only difference between what you want (I guess ?) and what AB is doing seems to be one of the following
> > > > > > > > > > 1. requestedtimedrefresh does not guarantee refresh rate
> > > > > > > > > > 2. not possible to refresh more frequently than 1 second.
> > > > > > > > > >
> > > > > > > > > > Traditionally, A tick is defined as a minimum move in price that is possible in an instrument. In AB, I gather a tick is both defined as a course of sale as well as a 5 seconds interval,ie. 12 ticks a minute. So I'm not sure what you mean by rendering every tick. But if you want to render you charts for every new course of sale, then it is more possible. Is that what you want?
> > > > > > > > > >
> > > > > > > > > > --- In amibroker@xxxxxxxxxxxxxxx, "Julian" <juliangoodsell@> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Tomasz,
> > > > > > > > > > >
> > > > > > > > > > > just to be clear from my side, as this thread has veered off course a little, I'm NOT suggesting running afl scripts without a render, or threading out the afl processing from the GDI rendering.
> > > > > > > > > > > I'm NOT suggesting any changes to the current architecture.
> > > > > > > > > > >
> > > > > > > > > > > I'm asking for the ability to set refresh rates per chart, for which the functionality already seems to be there.
> > > > > > > > > > > Running indicator calculations without rendering is a waste of cpu time, and so is rendering charts that don't need to be.
> > > > > > > > > > > If I have a chart that only needs to be updated every minute, there's no point in AB trying to render it on every tick update.
> > > > > > > > > > >
> > > > > > > > > > > Allowing us to specify at what intervals we want individual charts to update, would save countless wasted cpu time.
> > > > > > > > > > >
> > > > > > > > > > > Regards,
> > > > > > > > > > > Julian.
> > > > > > > > > > >
> > > > > > > > > > > --- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <groups@> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hello,
> > > > > > > > > > > >
> > > > > > > > > > > > There is no sense in doing indicator calculation when this calculation
> > > > > > > > > > > > does not lead to actual rendering. That would be waste of CPU.
> > > > > > > > > > > > The purpose of doing indicator calculation is to actually display it (refresh it).
> > > > > > > > > > > > Indicators formulas are here to display something.
> > > > > > > > > > > >
> > > > > > > > > > > > If you want code that does not display anything, you should run it as
> > > > > > > > > > > > automatic-analysis (scan/exploration) code.
> > > > > > > > > > > >
> > > > > > > > > > > > Also AFL formula execution is often much faster than final GDI output,
> > > > > > > > > > > > therefore even if AFL formula was executed in parallel, it would still
> > > > > > > > > > > > face GDI contention because of Windows GDI system-wide lock.
> > > > > > > > > > > >
> > > > > > > > > > > > Only on Windows 7 this system-wide GDI lock is removed and only
> > > > > > > > > > > > there you could see graphic performance scaling
> > > > > > > > > > > >
> > > > > > > > > > > > Again, read the entire article:
> > > > > > > > > > > > http://blogs.msdn.com/e7/archive/2009/04/25/engineering-windows-7-for-graphics-performance.aspx
> > > > > > > > > > > >
> > > > > > > > > > > > Especially figure 4 GDI Concurrency and Scalability
> > > > > > > > > > > > - as you can see in any pre-Win7 systems, GDI does not scale *at all*
> > > > > > > > > > > > with adding threads.
> > > > > > > > > > > >
> > > > > > > > > > > > I can ensure you that I have actually *timed* many scenarios
> > > > > > > > > > > > and what I say is based on actual measurement and not on somebody's "belief".
> > > > > > > > > > > > That was one of the reasons I did not use GDI+ ("improvement" suggested by somebody on this list)
> > > > > > > > > > > > because real-world test revealed that it is 6 times slower than normal GDI.
> > > > > > > > > > > > Microsoft admitted that by the way in their recent demonstration on PDC (prof. dev. conference).
> > > > > > > > > > > >
> > > > > > > > > > > > So, all decisions regarding development of AmiBroker are not based on beliefs but on
> > > > > > > > > > > > hard code profiling evidence.
> > > > > > > > > > > >
> > > > > > > > > > > > Best regards,
> > > > > > > > > > > > Tomasz Janeczko
> > > > > > > > > > > > amibroker.com
> > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > From: "Yofa" <jtoth100@>
> > > > > > > > > > > > To: <amibroker@xxxxxxxxxxxxxxx>
> > > > > > > > > > > > Sent: Sunday, July 12, 2009 9:47 PM
> > > > > > > > > > > > Subject: Re: [amibroker] Per Chart Refresh Rates
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > Hi Thomas,
> > > > > > > > > > > > >
> > > > > > > > > > > > >> Tomasz wrote in the "Data And PlugIn Speed" thread
> > > > > > > > > > > > >>I may add that the concept of independent rendering from multiple threads
> > > > > > > > > > > > >>although attractive from first look, it inevitably hits the wall of GDI
> > > > > > > > > > > > >>which in all current versions of Windows has
> > > > > > > > > > > > >> single system-wide exclusive global lock, which means that only ONE thread
> > > > > > > > > > > > >> can actually render at one time. This means that adding threads does not
> > > > > > > > > > > > >> give you better performance.
> > > > > > > > > > > > >
> > > > > > > > > > > > >>The truth is that all current releases of Windows are not particularly
> > > > > > > > > > > > >>suited for multi-core/multi-CPU
> > > > > > > > > > > > >>but good news is that Microsoft apparently have given these limitations
> > > > > > > > > > > > >>some thought and
> > > > > > > > > > > > >>many of them are removed in Windows 7.
> > > > > > > > > > > > >
> > > > > > > > > > > > > That is true for rendering only! (Apps main thread is allowed to write the
> > > > > > > > > > > > > GDI device. So rendering is limited to a single thread.)
> > > > > > > > > > > > >
> > > > > > > > > > > > > But indicator calculation (and trading logic) could get executed by any
> > > > > > > > > > > > > threads. Am I right? So doing the calculation on a background thread than
> > > > > > > > > > > > > doing chart painting with the "main" thread would increase processor usage
> > > > > > > > > > > > > and increase chart refresh reate? (I guess we all have dual and quad core
> > > > > > > > > > > > > CPUs...)
> > > > > > > > > > > > >
> > > > > > > > > > > > > How about separating "calculation refresh rate" and "chart refresh rate"? So
> > > > > > > > > > > > > I could request my panel to execute 3 times per sec without chart repaint
> > > > > > > > > > > > > (this could be executed by any threads) and refresh visible chart in every
> > > > > > > > > > > > > 3rd sec (this requires rendering, so calculation is done by a background
> > > > > > > > > > > > > thread, and painting is done by main thread))?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Any thoughts?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Regards,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Y
> > > > > > > > > > > > >
> > > > > > > > > > > > > (I know it is not doable in a day work, but I guess all short
> > > > > > > > > > > > > term/daytraders are having trouble bacause of refresh limitations.)
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > --------------------------------------------------
> > > > > > > > > > > > > From: "Julian" <juliangoodsell@>
> > > > > > > > > > > > > Sent: Sunday, July 12, 2009 8:14 PM
> > > > > > > > > > > > > To: <amibroker@xxxxxxxxxxxxxxx>
> > > > > > > > > > > > > Subject: [amibroker] Per Chart Refresh Rates
> > > > > > > > > > > > >
> > > > > > > > > > > > >> Hi Tomasz, I thought I'd start a new thread on this topic as I think it's
> > > > > > > > > > > > >> an interesting one.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Tomasz wrote in the "Data And PlugIn Speed" thread
> > > > > > > > > > > > >>> I may add that the concept of independent rendering from multiple threads
> > > > > > > > > > > > >>> although attractive from first look, it inevitably hits the wall of GDI
> > > > > > > > > > > > >>> which in all current versions of Windows has
> > > > > > > > > > > > >> single system-wide exclusive global lock, which means that only ONE thread
> > > > > > > > > > > > >> can actually render at one time. This means that adding threads does not
> > > > > > > > > > > > >> give you better performance.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> In response to that Tomasz,
> > > > > > > > > > > > >> you're referring to performance on the basis of multiple charts being
> > > > > > > > > > > > >> rendered per refresh update.
> > > > > > > > > > > > >> E.g. If you have ten charts on screen, and they take a total of 2 seconds
> > > > > > > > > > > > >> to render, then there's little performance gain to be had by threading
> > > > > > > > > > > > >> them because of the GDI lock. That is fine and I get that.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> But what I'm referring to is the ability to control which charts render
> > > > > > > > > > > > >> when, so that all ten don't have to be updated every refresh.
> > > > > > > > > > > > >> The problem is that in real time mode with the refresh interval set to 0
> > > > > > > > > > > > >> in the preferences, if I have a tick chart that only takes 10ms to update,
> > > > > > > > > > > > >> it's still only going to be rendered every 2 seconds because that's how
> > > > > > > > > > > > >> long the other nine charts take to render, even though I don't need them
> > > > > > > > > > > > >> to be updated multiple times per second, but maybe only once every 5
> > > > > > > > > > > > >> seconds or even every minute.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> If we could set refresh rates per chart, then you could have time critical
> > > > > > > > > > > > >> tick charts update as fast as possible, and longer timeframe or more time
> > > > > > > > > > > > >> expensive/less critical charts only update every 5 seconds or even longer.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> By staggering chart updates, traders would have much greater control over
> > > > > > > > > > > > >> performance and not waste so much processing power updating charts that
> > > > > > > > > > > > >> don't need to be. This would trounce any other kind of performance
> > > > > > > > > > > > >> improvement that could be gained by optimizing the rendering engine
> > > > > > > > > > > > >> itself, and would require no threading or any real change to the current
> > > > > > > > > > > > >> architecture that I can see.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Moreover, it appears this functionality is already in AB, but just that
> > > > > > > > > > > > >> there's no way for the user to control it.
> > > > > > > > > > > > >> The requestTimedRefresh() function enables you to update only the chart it
> > > > > > > > > > > > >> is applied to, so they can obviously be rendered independently of each
> > > > > > > > > > > > >> other.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> The problem though is that it is not enforceable. If I specify a refresh
> > > > > > > > > > > > >> interval of 1 in the preferences, and then requestTimedRefresh(10) on a
> > > > > > > > > > > > >> chart, that chart still gets updated every second along with all the
> > > > > > > > > > > > >> others, and then once more after ten seconds.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Giving the option to make requestTimedRefresh() enforceable would be one
> > > > > > > > > > > > >> way of enabling this functionality. Perhaps add an enforceable parameter
> > > > > > > > > > > > >> to the function like:
> > > > > > > > > > > > >> requestTimedRefresh(10, onlyvisible=True, enforceable=false).
> > > > > > > > > > > > >> Then if I specify requestTimedRefresh(10, true, true), that chart should
> > > > > > > > > > > > >> only update every 10 seconds, irrespective of what I've set in the
> > > > > > > > > > > > >> preferences.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Would this be as easy to implement as I think it is? If so, I think the
> > > > > > > > > > > > >> benefits would be rather large.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Jules.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> ------------------------------------
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> **** IMPORTANT PLEASE READ ****
> > > > > > > > > > > > >> This group is for the discussion between users only.
> > > > > > > > > > > > >> This is *NOT* technical support channel.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> TO GET TECHNICAL SUPPORT send an e-mail directly to
> > > > > > > > > > > > >> SUPPORT {at} amibroker.com
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
> > > > > > > > > > > > >> http://www.amibroker.com/feedback/
> > > > > > > > > > > > >> (submissions sent via other channels won't be considered)
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> > > > > > > > > > > > >> http://www.amibroker.com/devlog/
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Yahoo! Groups Links
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > ------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > **** IMPORTANT PLEASE READ ****
> > > > > > > > > > > > > This group is for the discussion between users only.
> > > > > > > > > > > > > This is *NOT* technical support channel.
> > > > > > > > > > > > >
> > > > > > > > > > > > > TO GET TECHNICAL SUPPORT send an e-mail directly to
> > > > > > > > > > > > > SUPPORT {at} amibroker.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
> > > > > > > > > > > > > http://www.amibroker.com/feedback/
> > > > > > > > > > > > > (submissions sent via other channels won't be considered)
> > > > > > > > > > > > >
> > > > > > > > > > > > > For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> > > > > > > > > > > > > http://www.amibroker.com/devlog/
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yahoo! Groups Links
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
------------------------------------
**** IMPORTANT PLEASE READ ****
This group is for the discussion between users only.
This is *NOT* technical support channel.
TO GET TECHNICAL SUPPORT send an e-mail directly to
SUPPORT {at} amibroker.com
TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
http://www.amibroker.com/feedback/
(submissions sent via other channels won't be considered)
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
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/
|
