|
PureBytes Links
Trading Reference Links
|
Hello,
> 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?
Sub-second resolution is not just restructuring database - it is a breaking change for entire API because timestamp with milisecond
resolution AND scope of 1900-2155 would need to be 64-bit, that means adding support 64 data type to *ALL* afl functions
effectivelly
doubling the code (since polymorphic versions of all functions must be added) changing the way custom fixed-size allocators and many
other details also the AmiVar structure is no longer 8 bytes
and that means *ALL* indicator plugins written upto date (including 3rd party that I don't have sources for) need (at least)
recompile.
Of course all data plugins need rewrite, but that's obvious. Essentially it means flipping all lines of code (millions) upside down.
I know it is my problem only but I just wanted to show that it is not just lack of "caring" as some may suggested.
Best regards,
Tomasz Janeczko
amibroker.com
----- Original Message -----
From: "Paul Ho" <paul.tsho@xxxxxxxxx>
To: <amibroker@xxxxxxxxxxxxxxx>
Sent: Tuesday, July 14, 2009 3:00 PM
Subject: [amibroker] Re: Per Chart Refresh Rates
> 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
>
>
>
------------------------------------
**** 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/
|