PureBasic Forums - English

is this what you were looking for Dare2?
http://board.win32asmcommunity.net/show ... eadid=3536

Hi Jack,

Thanks.

I don't know that it was those exactly (i was just browsing at the time and don't have a clear recollection of what and where - think it was more specific, not macro).

But they look good and that may be a better approach.

Hi everyone,

Thanks for all the replies but I'm still waiting for somebody to let me know how long the example floating point calculation takes in PureBasic.

As I mentioned, I only have the evaluation version and thus have no chance to test the speed myself. I have run the same code in VB and would like to know whether there is much difference in speed.

Thanks in advance.

@davies:
It doesnt make sense if somebody here tells you how fast
the PureBasic code runs on his computer and you compare
it with the VB results on your computer.
This is like comparing 133 MHz to 3 GHz -> means you have
to make both tests (VB and PB) on the same computer under
the same conditions.

Also, you didnt show your code for time measurement and
the VB code.

I uploaded PB + PB-ASM source and exe for you, so you can
test it on your own computer: speed_davies.zip

Note that i had to change the loop from 100.000.000 (100 millions)
to 10.000.000 (10 millions), otherwise the result in FPU gets
corrupt/invalid float, see this: Maybe you used double floats in VB?

Set the loop in VB to 10 millions and test again with the same
measurement method like in my PB source, so you can compare
yourself on your computer.

Hi Danilo,

Many thanks for testing the code out for me. Yes, I used a "Double" variable for the calculation in VB.

Here is what I get on my 2.4 GHz P4 system:

PB: 110 ms
directASM: 30 ms
VB: 30 ms

That's very interesting. It seems that VB and directASM are the same, at least or this very simple example. Though I wonder if the relatively short time (30 ms) makes it difficult to distinguish between the two?

Thanks again.

davies wrote:Yes, I used a "Double" variable for the calculation in VB.

Can you test also with floats in VB (should be 'single' or so) please?

We had a test in german forum some time ago that showed
that double floats were faster than single floats.

Of course it can be different on different processors (FPUs),
maybe todays FPUs are more optimized for 64bit floats.
Depends also on the manufacturer, AMD <> iNTEL - some
things are better optimized in AMD CPUs/FPUs, other things
are better on iNTEL CPUs/FPUs.

(btw: Fred is working on doubles and quads for PB 4.0, should
be available in round about 3 month)

davies wrote:That's very interesting. It seems that VB and directASM are the
same, at least or this very simple example.
Though I wonder if the relatively short time (30 ms) makes it
difficult to distinguish between the two?

If you used the same test code in VB (give the test process
realtime priority), its very exact measurement, otherwise a
task switch could disturb the test and make a wrong result.

I dont know how VB optimizes this test, but some compilers
(VC++, Intel C++) completely replace loops sometimes if it
can be calculated at compile time (all variables are known
to the compiler at compile time, so it would be possible).
But then it wouldnt take 30ms anyway, so it "looks" like VB
just generates good code for this test-loop.

(btw: Fred is working on doubles and quads for PB 4.0, should
be available in round about 3 month)

8O WOOHOO!

Well I've decided to champion the Linux version of PB so lets hope Linux PB gets Doubles and Quads in 3 months too

Hi Danilo,

Thanks for the reply. In fact, the example I gave can be calculated straight away (as shown below) so do you think the VB and directASM versions are doing that instead of the actual loops?

The following code:

yy=1.000001
zz=1
For x=1 to N
zz = zz * yy
Next x

is (off the top of my head) equivalent to:

zz = yy^N

so:

ln|zz| = ln|yy^N| = N * ln|yy|

thus:

zz = e^(N * ln|yy|)

I guess this calculation could be done very quickly indeed.

Regards.

davies wrote:Another constraint I have is that the simulations will need to be understood by undergraduate students, some of whom have only a small knowledge of computer programming. In this case I am limited to a BASIC language which compiles to give fast programmes "out of the box" without the need for tweaking of ASM.

With this constraint you need to wait until double math is fully integrated into the language.

There are a number of ways to access 80 bit FPU instructions, for example some of us have used 10 byte "string" variables.

But for simulation you will likely need to access float arrays efficiently and this will be messy until double arrays are available.

I have done numerous physics simulations and never had need for 80 bit variables. I would recommend using the more useful standard of IEEE 64 bit floats if possible. The fast 80 bit FPU will still be used for the calculations and the answers will be accurate to the full range of the 64 bit doubles.

With proper support for doubles, Purebasic will become a great language for your application and many others that demand accuracy.