|
PureBytes Links
Trading Reference Links
|
Guys
There are two suggestions that should concern participants of this thread, if you're interested in changing the resolution of timestamp to sub 5 seconds. please take a look at suggestion 1691 : http://www.amibroker.com/feedback/view_bug.php?bug_id=1691&start_at=0 . Another one which could also be of interest is about float point volume. #636 http://www.amibroker.com/feedback/view_bug.php?bug_id=636 .
As far as I'm concerned, as long as we have a one second resolution. I'm happy enough. But if Tomasz is going to the trouble to re-structuring the database, why not build in some margin for future growth?
If you guys wants what we've talked about not gone emptied handed. take a few minute to have a look these 2 suggestions.
Paul.
--- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <groups@xxx> wrote:
>
> Hello,
>
> My post was solely to point out that
> the Feedback Center (FC) http://www.amibroker.com/feedback/
> is the only place to make suggestions. Other means will be simply ignored
> because of the inefficiency. Only FC offers required organisation
> and is compatible with development environment.
> I simply can not afford reading through tons of talk
> to locate one line in which someone wants something implemented.
> That is a waste of time I was mentioning.
> So please feel free to discuss, but don't expect me to note of your suggestions
> spread in the middle of 10 page talk. Use the feedback center
> or support channel to make any requests.
>
> And to people talking about adding sub-second resolution to timestamp:
> you are simply forgetting one fact.
> No supported DATA SOURCE offers resolution higher than 1 second.
> They are all down to 1 second AT BEST. Not so rare are tick data with only 1-minute resolution (IQFeed until recently was such
> example).
> There is simply no sub-second data available.
>
> Why would one add a feature when there is no data available ?
>
> Please point out to single data vendor (for retail clients) that offers subsecond timestamps
> and offers backfill with subsecond timestamps.
>
> I don't know of any.
>
> Best regards,
> Tomasz Janeczko
> amibroker.com
> ----- Original Message -----
> From: "Julian" <juliangoodsell@xxx>
> To: <amibroker@xxxxxxxxxxxxxxx>
> Sent: Tuesday, July 14, 2009 12:18 PM
> Subject: [amibroker] Re: Per Chart Refresh Rates
>
>
> > Ouch! What a killjoy. :)
> >
> > That's fair enough from your point of view Tomasz, but this is a user forum, and the mulling over of ideas whether ignorant,
> > uneducated or completely missing the point is all fair game.
> >
> > I'm well aware of the limited (probably zero) impact of these forum posts in relation to your actual development of AB, but
> > posting them gets a lot of ideas out and solves a lot of problems in itself. I've answered heaps of my own questions, just by
> > writing posts, many of which I never need to end up sending, and which in hindsight were foolish. Of course there's always some
> > that get through the filter. :)
> >
> > There are innumerable posts on this forum from beginners and non programmers that I think are stupid, but I don't bother writing
> > to let them know!
> >
> > So my advice is to stick to development and leave the forum nonsense to us. :)
> >
> > Tongue in cheek,
> > Jules.
> >
> > --- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <groups@> wrote:
> >>
> >> Hello,
> >>
> >> I am sorry to say this but this thread is just waste of time.
> >> You may discuss things to death yet it has zero result in terms of program itself.
> >> Naive views/opinions/beliefs from most participants of this thread are pretty much do not have any impact on development of
> >> AmiBroker
> >> simply because development plans are made many years ahead and features you are discussing now were planned 3 years ago long
> >> before
> >> you knew AmiBroker exists. Moreover they are on the Feedback Center for years already (if somebody bother to check already
> >> submitted things).
> >> In contrast to cheap forum talk, the program development does not occur overnight. If you think that you will
> >> talk for a month about some feature and it will arrive just because you talked a lot you are wrong.
> >> There are zillions of things (half of them are not technical at all) that decide when and what way given thing is implemented
> >> and you are not aware of 90% of them.
> >> So my advice is to stick to trading and leave the development to me.
> >>
> >> Best regards,
> >> Tomasz Janeczko
> >> amibroker.com
> >> ----- Original Message -----
> >> From: "brian_z111" <brian_z111@>
> >> To: <amibroker@xxxxxxxxxxxxxxx>
> >> Sent: Tuesday, July 14, 2009 5:12 AM
> >> Subject: [amibroker] Re: Per Chart Refresh Rates
> >>
> >>
> >> > 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
> >> >
> >> >
> >> >
> >>
> >
> >
> >
> >
> > ------------------------------------
> >
> > **** 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/
|