|
PureBytes Links
Trading Reference Links
|
TJ,
yes, it was not fair. But I felt upset and like suffering a snub as a customer
(and again, not for the first time). There is a proverb: "It's not what you
say, but how you say it." And yes, I know that English is not your native
language - neither is it for me.
But no worry - that's my last post in this list. I take your advice and stick
to trading.
On 14.07.2009, 14:55:02 Tomasz Janeczko wrote:
> 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/engin
> >> > >> > > > > > > > > >eer 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
>
>
>
------------------------------------
**** 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/
|