integer too slow

BackupUser · Post by **BackupUser** » Thu Mar 20, 2003 8:16 pm

Restored from previous forum. Originally posted by fred.

All speed tests are good to know and will help me to build a faster compiler.

Fred - AlphaSND

BackupUser · Post by **BackupUser** » Thu Mar 20, 2003 9:24 pm

Restored from previous forum. Originally posted by geoff.

Again off topic but it may interest some of you that the 2D float array math above was part of a benchmark written 20 years ago to compare languages and computers for finite element computer modelling.

I have run this on every computer I have used in that period.

My current home computer (1400 celeron tualatin) is about 100000 times faster than the home computer I had in 1985, a similar ratio as a second to a day. Perhaps even more impressive is that it is about 1000 times faster than a â‚¬150000 computer I was using at work 15 years ago.

In that context, a speed ratio of 2 doesn't seem all that important does it?

BackupUser · Post by **BackupUser** » Thu Mar 20, 2003 9:54 pm

Restored from previous forum. Originally posted by ricardo.

Sometimes is a little tricky to do this beenchmarks, when i do this one, BCX is faster tha PB, but if i do almost the same but use STR() then PB is faster.
However here is my test:

Code: Select all

Dim A.l(100000)

If OpenConsole()
  PrintN("Start")
  Time0=GetTickCount_()
  For Counter = 1 To 100000
    For Counter1 = 1 To 100
      For Counter2 = 1 To 100
        A(Counter) = Counter
      Next Counter2
    Next Counter1
  Next Counter
  Time1=GetTickCount_()
  Result = Time1 - Time0
  PrintN(Str(Result))
  Beep_(1000,50)
  
  PrintN( "-------------------------------------")
  
  PrintN("Press Enter To Quit ")
  Void$=Input()
EndIf

BCX:

Code: Select all

DIM A%[100000]
DIM Void$
DIM Counter%
DIM Counter1%
DIM Counter2%
DIM Time%
DIM Time1%
DIM Result%


PRINT "Start"
Time%=GetTickCount()
FOR Counter% = 1 TO 100000
  FOR Counter1% = 1 to 100
    FOR Counter2% = 1 to 100
      A%[Counter%] =  Counter%
    NEXT Counter2%
  NEXT Counter1%
NEXT Counter%
Time1%=GetTickCount()
Result% = Time1% - Time% + 5
? Result%
Beep(1000,50)

? "-------------------------------------"

INPUT "Press Enter To Quit " , Void$

Results:

PB: 26388
BCX: 20475

Best Regards

Ricardo

Dont cry for me Argentina...

BackupUser · Post by **BackupUser** » Fri Mar 21, 2003 6:47 pm

Restored from previous forum. Originally posted by geoff.

Use STR() where Ricardo?

As long as the code below is unchanged I get almost exactly the same result every time running Purebasic in console mode or Windows mode.

Are you creating an EXE and running that?
Are you closing down all other applications?
Is Windows running any TSR programs?

Code: Select all

Time0=GetTickCount_()
  For Counter = 1 To 100000
    For Counter1 = 1 To 100
      For Counter2 = 1 To 100
        A(Counter) = Counter
      Next Counter2
    Next Counter1
  Next Counter
Time1=GetTickCount_()

I get 6850 (Celeron Tualatin 1400, BX Motherboard, 100MHz FSB)

BackupUser · Post by **BackupUser** » Fri Mar 21, 2003 7:17 pm

Restored from previous forum. Originally posted by ricardo.

Originally posted by geoff

Use STR() where Ricardo?

Code: Select all

Time0=GetTickCount_()
  For Counter = 1 To 100000
    For Counter1 = 1 To 100
      For Counter2 = 1 To 100
        A(Counter) = Str(Counter); of course the array should be string arrays
      Next Counter2
    Next Counter1
  Next Counter
Time1=GetTickCount_()

BCX is slower on STR$() i think its because it creates some procedure to work it, so the code isnt really the same anymore, thats why i dont make the test using STR$().

Are you creating an EXE and running that?
Are you closing down all other applications?
Is Windows running any TSR programs?

Yes creating a console exe, because my BCX test was a console. Both compiled.
-Yes closing down.
-Nop.

I make the test with BCX because the syntaxis is very similar, but more because its a 'basic to c' translator and we could say that PureBasic is an 'basic to asm' translator.

But as i said, i think that its a little tricky to make beenchmarks like this one.

I think that any serious beenchmarks must make a lot of tests with different codes (covering the basic aspects like long, word, strings, arrays, etc.) and then make a percent of all the results. I realise that one simple code could be done to make that one of the compilers has a better timing, change the code a bit and play with them and you can have the result that you want.

Thats why a real beenchmark must be done with many codes that covers more aspects of the languages, comparing just ONE small code dosent mean nothing...

Best Regards

Ricardo

Dont cry for me Argentina...

BackupUser · Post by **BackupUser** » Fri Mar 21, 2003 8:02 pm

Restored from previous forum. Originally posted by mdkrsta.

but can help to find the weak spots

BackupUser · Post by **BackupUser** » Fri Mar 21, 2003 8:21 pm

Restored from previous forum. Originally posted by geoff.

Thanks, Ricardo.

Yes I agree, benchmarks can be completely misleading. And when you run benchmarks under an OS like Windows you have to be very careful that you are measuring what you think you are measuring because Windows always has a number of processes in memory at the same time.

However, sometimes simple benchmarks can be useful. The simple float array benchmark I listed above was written for a very specific purpose, to get an idea how fast finite element mathematical models would run on a system. In fact subsequent work showed this benchmark to be a useful guide. But of course, that's all it does, it is of no use in predicting performance of other applications.

For this very specific application, I generally found Fortran compilers to be the fastest. This is probably because Fortran has been optimised for tasks of this sort for many years.

But there is no reason that one language is inherently any faster than another because ultimately they all compile to the same machine instruction set. So Purebasic could produce the fastest code on Earth, in theory anyway.

BackupUser · Post by **BackupUser** » Sat Mar 22, 2003 9:35 am

Restored from previous forum. Originally posted by Voldemort.

But there is no reason that one language is inherently any faster than another because ultimately they all compile to the same machine instruction set.

It depends on HOW the ultimate compilation to machine code is done. Machine code can be very unoptimized and slow if done poorly.

BackupUser · Post by **BackupUser** » Sat Mar 22, 2003 4:33 pm

Restored from previous forum. Originally posted by Kale.

Machine code can be very unoptimized and slow if done poorly.

Darkbasic/Pro

--Kale

In love with PureBasic!

BackupUser · Post by **BackupUser** » Tue Mar 25, 2003 8:18 am

Restored from previous forum. Originally posted by flim.

[quote
Here is the code for PureBasic (needs 17 sec):
OpenConsole()
ti=gettickcount_()
Dim a(10)
b=2
For i=1 To 500000000
a(1)=a(2)+a(3)
a(b)=a(1)-a(2)
a(2)=17+i
a(3)=100-a(2)
Next
res=Print(Str(gettickcount_()-ti))
a$=Input()

The same code for BlitzBasic (needs 9 sec):
ti=MilliSecs()
Dim a(10)
b=2
For i=1 To 500000000
a(1)=a(2)+a(3)
a(b)=a(1)-a(2)
a(2)=17+i
a(3)=100-a(2)
Next
Print MilliSecs()-ti
[/quote]

B3D 1.83 - 16554
PB 3.62 - 10895

BackupUser · Post by **BackupUser** » Tue Mar 25, 2003 8:33 am

Restored from previous forum. Originally posted by Berikco.

B3D 16554
PB 10895
??
Wich is the correct result?
Can you mail me the blitz exe, i like to test here?
[url]mailto:berikco@pandora.be">berikco@pandora.be

Regards,

Berikco

<a href="http://users.pandora.be/berikco/purebasic.htm[/url]

BackupUser · Post by **BackupUser** » Tue Mar 25, 2003 8:42 am

Restored from previous forum. Originally posted by flim.

Yes that's the correct result, I test several time and that's the best result of B3D.

Both test from the IDE, not final .exe

Re-run the test from compiled .exe

B3D 1.83 - 16639
PB 3.62 - 10996

1GHz PIII/384M RAM/Windows 2000

BackupUser · Post by **BackupUser** » Tue Mar 25, 2003 8:47 am

Restored from previous forum. Originally posted by Berikco.

So PureBasic is much faster, is it typo in your first post?
Ahh, i see, you killed the quote in your post

Regards,

Berikco

http://users.pandora.be/berikco/purebasic.htm

BackupUser · Post by **BackupUser** » Tue Mar 25, 2003 8:53 am

Restored from previous forum. Originally posted by flim.

Yes PB is much faster in this test.

BackupUser · Post by **BackupUser** » Sun Mar 30, 2003 8:29 am

Restored from previous forum. Originally posted by theogott.

First to this threads Subject: INTEGER TOO SLOW.
As a statement its simply wrong.

Secondly I am really not shure if that is the place where to spent the time for developers.

WHY ?

1. Integer-Speed is highly CPU-dependent.
2. New CPU, the carefully done optimizations revert back into opposite.
3. Diffrent CPU-Architectures out there.
You can choose to optimize wheter for PIV OR for AMD Athlon.
But those processors are already fast enough for nearly
everything. Those who would need the code optimizations have a
Pentium MMX. However I doubt fred wants to optimize for U & V -
Pipeline. Even then what doo the K6-II und III Owners say ?

4. A general optimization OK. The last 10% I think its wasted time.
End of Year the 64-bit Opteron will be avaibale. A lot of carefull
done Optimizations may be useless then or even make the code
worse.

Example: In Pentium times "Loop unrolling" was popular to make things faster. (Less branches). Nowadays the Loop just may "roll out of the of the L1 cache" of these or the other CPU.

Then optimizing makes things slower.
There are quit a lot optimizations that were Ok for the Pentium mot more on the PII/III and then some that were OK on the PIII - not more on the PIV ... and diffrent once on the AMD. We are talking about Speed diffrences from ~20% Speed for a Subroutine from just changing the CPU-Architecture from Intel to AMD.

However if there would be ideas to use for example SSE (or a SSE-Switch for SSE-Optimization) in PB then I'd be PRO cause I have it ...

*************************
The best time to do things is now !