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