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

Re: [amibroker] Re: Per Chart Refresh Rates



PureBytes Links

Trading Reference Links

Thomas,

So this "not caring about customers" is of course is exemplified 14 years of 
listening to customers and release history
that shows tens of thousands *user* wishes actually implemented:
http://www.amibroker.com/devlog/

How fair...

Best regards,
Tomasz Janeczko
amibroker.com
----- Original Message ----- 
From: "Thomas Ludwig" <Thomas.Ludwig@xxxxxx>
To: <amibroker@xxxxxxxxxxxxxxx>
Sent: Tuesday, July 14, 2009 2:25 PM
Subject: Re: [amibroker] Re: Per Chart Refresh Rates


> 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
> 
> 
> 


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

**** 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/