|
PureBytes Links
Trading Reference Links
|
Hello,
I understand your point, however such idealistic situation (like refresh only once a minute) is somewhat rare
because of user interaction (zooming/scrolling/drawing object on chart, etc) that all involve refresh.
Also allowing to have "very complex" indicators to refresh only once a minute
would inevitably lead to people writing codes that for example need 40 seconds to execute per refresh.
And that will result in having unresponsive zooming/scrolling/etc.
The only resonable way to allow very complex codes executing for 10+ seconds
to do graphic output is to allow rendering static images that don't allow user interaction like scroll/zoom/drawing.
Best regards,
Tomasz Janeczko
amibroker.com
----- Original Message -----
From: "Julian" <juliangoodsell@xxxxxxxxxxxx>
To: <amibroker@xxxxxxxxxxxxxxx>
Sent: Monday, July 13, 2009 2:09 AM
Subject: [amibroker] Re: Per Chart Refresh Rates
> 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@xxx> wrote:
>>
>> Hello,
>>
>> There is no sense in doing indicator calculation when this calculation
>> does not lead to actual rendering. That would be waste of CPU.
>> The purpose of doing indicator calculation is to actually display it (refresh it).
>> Indicators formulas are here to display something.
>>
>> If you want code that does not display anything, you should run it as
>> automatic-analysis (scan/exploration) code.
>>
>> Also AFL formula execution is often much faster than final GDI output,
>> therefore even if AFL formula was executed in parallel, it would still
>> face GDI contention because of Windows GDI system-wide lock.
>>
>> Only on Windows 7 this system-wide GDI lock is removed and only
>> there you could see graphic performance scaling
>>
>> Again, read the entire article:
>> http://blogs.msdn.com/e7/archive/2009/04/25/engineering-windows-7-for-graphics-performance.aspx
>>
>> Especially figure 4 GDI Concurrency and Scalability
>> - as you can see in any pre-Win7 systems, GDI does not scale *at all*
>> with adding threads.
>>
>> I can ensure you that I have actually *timed* many scenarios
>> and what I say is based on actual measurement and not on somebody's "belief".
>> That was one of the reasons I did not use GDI+ ("improvement" suggested by somebody on this list)
>> because real-world test revealed that it is 6 times slower than normal GDI.
>> Microsoft admitted that by the way in their recent demonstration on PDC (prof. dev. conference).
>>
>> So, all decisions regarding development of AmiBroker are not based on beliefs but on
>> hard code profiling evidence.
>>
>> Best regards,
>> Tomasz Janeczko
>> amibroker.com
>> ----- Original Message -----
>> From: "Yofa" <jtoth100@xxx>
>> 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@xxx>
>> > 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
<*> 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/
|