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
