Thanks to Tomasz. He rightly said " So it is not AB.
It is THE USER who controls it. " I primarily run the AFL(3000 lines of code) in AA mode and scan every minute. I had lot of functions such as HHV, LLV,MACD and timeframeexpands called manytimes in the AFL code. Suggestion from Amibroker Support was to define these once and reuse the variabes instead of calling the functions so many times. I was coding each of the strategies seperately and then pasting into this big AFL which caused the repetions. I am working on fixing these, specifically the timeframeexpand that I heavily use. Infact I dont even know if there are softwares out there that let you us multitimeframe fucntions like Amibroker does. TJ also pointed out that using vb scripts,filesystem objects, fso write functions are slow in nature. These are called outside of Amibroker. These have nothing do with AFL. I was using these vbscripts to create a csv interface to metatrader rather than use API calls etc. So these scripts run slow. Many Thanks to TJ on explaining the problem areas add suggestions. As I make these changes I see huge improvement in the cpu. Issue resolved. Last but not least and I have said this many times in the past. Amibroker Support Rocks. !!!! Cheers,Padhu ----- Original Message ----- From: qavatina To: [email protected] Sent: Tuesday, October 02, 2007 3:03 PM Subject: [amibroker] Re: Amibroker High CPU Utilization-anyone else seeing this?. I had a lot of "RequestTimedRefresh( 1, False );" in my code. I reduced them to one and the CPU load came down from 90% to around 10%. --- In [email protected], "Tomasz Janeczko" <[EMAIL PROTECTED]> wrote: > > Hello, > > How many times I have to explain that in ANY program that allows custom formulas, > the USER can write formula that will executed slow. And this is exactly what is happening. > > The USER wrote the formula badly and I offered him help in fixing HIS formula. > Any formula can be written so bad that it will execute 1000x slower than it should. > > I can take Visual C++ or Assembler or any language and I can demonstrate that I can write > the code that will take one hour, month or year to execute. And this has ABSOLUTELY NOTHING > to do with the language you are using. > > So it is not AB. > It is THE USER who controls it. > > Any formula that is shipped with AmiBroker executes well below 0.1 second and causes less than few percent CPU load. > > AmiBroker runs at PHENOMENAL speed ! > > See the example code: > GetPerformanceCounter(1); > > for( i = 0; i < 10000; i++ ) > { > x = High + Low; > } > > NumberOfOperations = BarCount * i; > > timeperadd = GetPerformanceCounter(1); > > > > for( i = 0; i < 10000; i++ ) > { > y = x / 2; > } > > timeperdiv= GetPerformanceCounter(1); > > StrFormat("Total Number of operations = %12.12g", NumberOfOperations ); > StrFormat("Total time of additions [milliseconds] = %.2f", timeperadd ); > StrFormat("Time per one addition [milliseconds] = %.9f", timeperadd/NumberOfOperations ); > StrFormat("Number of additions per second = %12.12g", 1000/(timeperadd/NumberOfOperations) ); > StrFormat("Total time of divisions [milliseconds] = %.2f", timeperdiv ); > StrFormat("Time per one divisions [milliseconds] = %.9f", timeperdiv /NumberOfOperations ); > StrFormat("Number of divisions per second = %12.12g", 1000/(timeperdiv /NumberOfOperations) ); > > > On 2GHz Athlon the results are as follows: > > Total Number of operations = 18040000 > Total time of additions [milliseconds] = 50.25 > Time per one addition [milliseconds] = 0.000002785 > Number of additions per second = 359021216 > Total time of divisions [milliseconds] = 85.39 > Time per one divisions [milliseconds] = 0.000004733 > Number of divisions per second = 211270320 > > (Test was performed on 101000 bars data, that accounts for 3MB - which is MORE than on-chip cache size, therefore memory access times were accounted in, > note that tests involve arithmetic operation PLUS two memory reads and one memory write per iteration) > > That gives phenomenal speed of > 359 MEGAFLOPS (addition) or 211 MEGAFLOPS (division) - where ONE MEGAFLOP is one million of floating point operations per second (including data read/write) > http://en.wikipedia.org/wiki/Megaflop > > This is about AS FAST AS this CPU is capable of running. > This is most amazing fact because it proves that AFL when running array operations runs AS FAST AS it would be possible if your code was written directly in MACHINE CODE > (taking into account regular floating point operations, *not* SSE, 3dNow or other SIMD) > In other words AFL has near-zero overhead when running array operations and can be compared with assembly language when running array operations. > > As a comparision JScript on the same machine runs at speed of only 0.8 MFLOPS (divisions). That shows that JScript 250 times slower than AFL. > > Bottom line: there is simply nothing faster than AFL. So if your formula executes slowly it is your formula bad coding, not AmiBroker. > > For the reference I have been running AmiBroker even on low end 133Mhz Pentium IN REAL TIME. > > And Amiga version of AmiBroker > was running OK even on 7MHz (yes SEVEN MEGAHERTZ == 0.007 GHz) processor and 1 MB (yes ONE megabyte) of RAM. > AFL engine exactly the same in both. > > Best regards, > Tomasz Janeczko > amibroker.com > ----- Original Message ----- > From: J. Biran > To: [email protected] > Sent: Tuesday, October 02, 2007 6:04 PM > Subject: RE: [amibroker] Amibroker High CPU Utilization-anyone else seeing this?. > > > One easy way to see if the CPU hog is AB or not, minimize AB. > > If CPU usage drops significantly, it is AB. > > > > Joseph Biran > ____________________________________________ > > From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Padhu > Sent: Tuesday, October 02, 2007 7:08 AM > To: [email protected] > Subject: Re: [amibroker] Amibroker High CPU Utilization-anyone else seeing this?. > > > > Thanks Tomasz. I have no no loops. No complex indicators. > > Just a lot of timeframe expands. > > > > I will try the AFL timing and see. If I am unable to find out I will send it to support. > > > > I have no doubt that AFL is the fastest out there. I have been using amibroker since 2004 and I love each and each every day of my experience with it. > > > > Its just that I am perplexed why the CPU would get bogged down like this. > > Thanks again. > > > > Will try the AFL timing you and Herman put together. > > Cheers,Padhu > > > > > > > > ----- Original Message ----- > > From: Tomasz Janeczko > > To: [email protected] > > Sent: Tuesday, October 02, 2007 3:34 AM > > Subject: Re: [amibroker] Amibroker High CPU Utilization-anyone else seeing this?. > > > > That's simple: > > one of your formulas is very badly coded - and it eats the CPU. > > > > Under normal circumstances the CPU floats in 8..20% use. > > > > You need to use Tools->Preferences->Miscellaneous and check "Display chart timing" > > then watch the timings each chart is showing. > > > > All built-in formulas execute well below 0.1 second and this should be your target. > > If any formula needs more than 0.5 sec to execute it is badly written and it should not be used. > > You must either rewrite it or send it to us and we will tell you what is wrong. > > But again: any formula that executes in more than 0.5 sec is NOT to be used in real-time > > and requires either rewrite or removal. > > > Best regards, > Tomasz Janeczko > amibroker.com > > ----- Original Message ----- > > From: Padhu > > To: [email protected] > > Sent: Tuesday, October 02, 2007 2:42 AM > > Subject: [amibroker] Amibroker High CPU Utilization-anyone else seeing this?. > > > > Folks: > > > > Attached is the task manager output when Amibroker 4.90.5 is runnning. It always spikes back and forth and stays very high near 90-100% . process shows broker.exe spiking. > > I have only 6 charts attached. > > > > I have noticed this in the past when I had indicators attached to more than 8 charts. Now I have only 6 six. Other than 1 , all other indicators are all fairly simple...no looping etc..But uses timeframe expands from daily etc. > > > > I have intel p4 2GHz cpu with 768MB ram. > > > > anyone else seeing this?. > > > > Thanks,Padhu >
