|
PureBytes Links
Trading Reference Links
|
Jules,
good answer. This was not the first example of a posting by TJ being unfriendly
to say the least. He could have shortened his answer to just one sentence: "I
don't care about my customers." Just as a proposal to make things more efficient
... :-((
On 14.07.2009, 12:18:44 Julian wrote:
> 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@xxx> 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@xxx>
> > 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/engineer
> > >> > > > > > > > > >ing-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/
|