Transform a piece of code in a DLL = better performance?

Author

Message

Alduce

23

Years of Service

User Offline

Joined: 26th Oct 2002

Location: Rama spaceship

Posted: 16th May 2013 11:04 Edited at: 16th May 2013 11:05

Link

Hi guys, I am running a desperate race against performances breakdown of my project. All what I can I must to do!.

I am thinking about to transform my code about "air particles collision and repositioning system" into a dll!

So at this point I need to ask you two questions :

1) Can I suppose that my piece of code will be handled faster than now by my cpu?

2) What are the steps I need to create a dll? Can I just to use a DBPro DBA file? and later what I need to do?

Thanks!

Back to top

Profile PM Website

TheComet

18

Years of Service

User Offline

Joined: 18th Oct 2007

Location: I`m under ur bridge eating ur goatz.

Posted: 16th May 2013 12:36

Link

1) Almost certainly, yes you can expect it will run faster.

2) You have to re-write it in C or C++. This guide is pretty useful: http://forum.thegamecreators.com/?m=forum_view&t=191280&b=18

TheComet

Yesterday is History, Tomorrow is a Mystery, but Today is a Gift. That is why it is called "present".

Back to top

Profile PM Email Website

Alduce

23

Years of Service

User Offline

Joined: 26th Oct 2002

Location: Rama spaceship

Posted: 16th May 2013 13:02 Edited at: 16th May 2013 13:05

Link

Ohh.. thank you TheComet!

So I can have a standard piece of my project code (where 4 FOR cycle run)as DLL right? I know is a stupid question but I need to have all clear about!
And...
Can I include in this DLL some DarkDynamix commands?...

Back to top

Profile PM Website

Dar13

18

Years of Service

User Offline

Joined: 12th May 2008

Location: Microsoft VisualStudio 2010 Professional

Posted: 16th May 2013 17:13

Link

Quote: "So I can have a standard piece of my project code (where 4 FOR cycle run)as DLL right?"

Whoa whoa hold up. You have 4 for-next loops? Have you tried to get rid of a couple of those?

The reason I say that is that a C/C++ DLL isn't going to magically solve your performance issues unless you're doing some really heavy math computations (intersections, physics collisions, distance checking, etc) and especially not when you have poorly optimized code structure.

WTLD has been put on indefinite hold.
A new project is under initial development now.

Back to top

Profile PM Email

Chris Tate

DBPro Master

17

Years of Service

User Offline

Joined: 29th Aug 2008

Location: London, England

Posted: 16th May 2013 21:26

Link

Quote: "The reason I say that is that a C/C++ DLL isn't going to magically solve your performance issues unless you're doing some really heavy math computations (intersections, physics collisions, distance checking, etc) and especially not when you have poorly optimized code structure."

Agreed. Your asking the wrong question; your be better off in programming if you focus on reduction. Try to reduce your calculations and features; use ready built solutions where possible. Sometimes features are not required; other times features can be changed, not the methods. And when methods need changing, that's down to poor choice of methods.

Another thing to do is time your calculations to find bottlenecks.

Back to top

Profile PM Email Website

Mr Bigglesworth

18

Years of Service

User Offline

Joined: 4th Mar 2008

Location:

Posted: 17th May 2013 02:51

Link

Quote: "1) Can I suppose that my piece of code will be handled faster than now by my cpu?"

Probably not very much, especially if you are mostly just calling commands from other plugins (DarkDynamix).

If you really want to speed it up if you are doing math calculations, write the dll's math functions in assembly language.

Back to top

Profile PM Email

Grasmann

17

Years of Service

User Offline

Joined: 1st Sep 2008

Location:

Posted: 19th May 2013 12:26 Edited at: 19th May 2013 12:42

Link

I don't think it will give you more performance.
Depending on the situations you can do some pretty simple things to speed up your program significantly.

For example in my current project I'm handling an array of objects.
The array size can easily be over 1.000.000 but not all elements are used. So if I loop through it I do it like this:

+ Code Snippet

local vocount as dword
local vo as dword
for vo = 1 to vo_size
   if vo_exist(vo)
      `Do something
      inc vocount
   endif
   if vocount >= vo_count
      exit
   endif
next vo

vo_size = Size of the array
vo_count = Count of objects ( Incremented at object creation )

Basically for each object that actually exists I increment vocount and compare it to the count of objects that really exist.
If my counted count is >= the actual count I exit the loop.

If my array has 1.000.000 elements and only one of them is used this loop how it is can make the difference between 1 loop and 1.000.000 loops.

Very simple but effective in this case.

A loop like below on the other hand would just do 1.000.000 loops for an array that is completely empty, what a waste of time XD.

+ Code Snippet

local vo as dword
for vo = 1 to vo_size
   if vo_exist(vo)
      `Do something
   endif
next vo

Back to top

Profile PM

Mobiius

Valued Member

23

Years of Service

User Offline

Joined: 27th Feb 2003

Location: The Cold North

Posted: 19th May 2013 13:58

Link

Quote: "local vo as dword"

This is unnecessary as all variables are local by default.

Quote: "vo as dword"

This will work the same.

I live for video games! (And beers, and football, and cars!)
See what I live for here: [url]http:\\www.TeamDefiant.co.uk[/url]

Back to top

Profile PM Email Website

Grasmann

17

Years of Service

User Offline

Joined: 1st Sep 2008

Location:

Posted: 19th May 2013 14:38 Edited at: 19th May 2013 15:31

Link

Yes I know but I like my locals XD.
I think with the "local" it just looks cleaner somehow.

But I also just realized Indigo, the IDE I'm using, colours the variables wrong if I declare them without "local".
Without it Indigo colours them as globals for whatever reason XD.

Another thing is I'm always delcaring variables with the datatype.
String for example I declare like that:

+ Code Snippet

local String$ as string

And I'm declaring all variables at the beginning of the function.
So if I look at the top of a function I can see all variables used in said function.

If you really want to get the best performance possible it's bad to have a function declare several variables that aren't even needed every time it'sc called.
In my current project I'm creating 10.000 objects in 19 ms or something like that.
So basically for every single variable in any of those functions I'm considering:
Do I really need this variable?
Am I able to achieve the goal with another method based on existing variables?
Or is it possible to tunnel the value directly?

For example if used very often this function ...

+ Code Snippet

FUNCTION vo_exist(vo AS DWORD)
	IF vo = 0 THEN EXITFUNCTION vo_FALSE
	IF vo > vobject_size THEN EXITFUNCTION vo_FALSE
	IF vobject(vo) = 0 THEN EXITFUNCTION vo_FALSE
ENDFUNCTION vo_TRUE

... Is more performant than this:

+ Code Snippet

FUNCTION vo_exist(vo AS DWORD)
	LOCAL Exist AS BOOLEAN
	IF vo > 0 AND vo <= vobject_size
		IF vobject(vo) > 0
			Exist = vo_TRUE
		ENDIF
	ENDIF
ENDFUNCTION Exist

The first version is faster simply because in some cases 1 equation is done while the second version always does at least 2 equations.
Also the second version is delcaring an unnecessary variable where I can give the values right back.
A nice side-effect is that IMO the first version is far easier to read and understand.

If you want to run this ~500.000 times in 19 ms ( not to mention the other code of course ) you have to think about every variable.
Well, or at least I'm doing this. XD

Back to top

Profile PM

Mobiius

Valued Member

23

Years of Service

User Offline

Joined: 27th Feb 2003

Location: The Cold North

Posted: 19th May 2013 16:02 Edited at: 19th May 2013 16:03

Link

Quote: "String$ as string"

Shouldn't that cause a compiler error as your essentially declaring String as string as string?

It's (what I call correctly) failed for me in the past?

But this:

+ Code Snippet

FUNCTION vo_exist(vo AS DWORD)
        LOCAL Exist AS BOOLEAN
        IF vo > 0 AND vo <= vobject_size
                IF vobject(vo) > 0
                        Exist = vo_TRUE
                ENDIF
        ENDIF
ENDFUNCTION Exist

Is the same as this:

+ Code Snippet

FUNCTION vo_exist(vo AS DWORD)
        IF vo > 0 AND vo <= vobject_size
                IF vobject(vo) > 0
                        Exist = vo_TRUE
                ENDIF
        ENDIF
ENDFUNCTION Exist

And this:

+ Code Snippet

FUNCTION vo_exist(vo AS DWORD)
   Exist = vo_FALSE
        IF vo > 0 AND vo <= vobject_size
                IF vobject(vo) > 0
                        Exist = vo_TRUE
                ENDIF
        ENDIF
ENDFUNCTION Exist

Declaring variables as local in functions makes no change to either missing the local identifier, or not declaring them at all.

I live for video games! (And beers, and football, and cars!)
See what I live for here: [url]http:\\www.TeamDefiant.co.uk[/url]

Back to top

Profile PM Email Website

Grasmann

17

Years of Service

User Offline

Joined: 1st Sep 2008

Location:

Posted: 19th May 2013 16:35 Edited at: 19th May 2013 16:42

Link

As I said I know that.

I just tried to explain why I like to declare them all like that since it's a performance-related topic anyways.

In really big functions you can lose track of all the variables you declare and if you look at the function some time later you realize you don't even need some of the variables.
I had that happen often enough.
It can't happen if you declare all your variables at the top, simple as that. XD

And believe me if you create a lot of unnecessary variables when running some code parts a few million times the performance will decrease if you are aiming for every possible ms. XD

Back to top

Profile PM

TheComet

18

Years of Service

User Offline

Joined: 18th Oct 2007

Location: I`m under ur bridge eating ur goatz.

Posted: 19th May 2013 21:43

Link

Grasmann has some good coding habits, I approve!

I really really wish DBP had the same help files as DBC did. It taught you the correct syntax of BASIC before delving into deeper topics. Things such as when to use REM and when to use ` for comments, or correct declaration of variables by using the suffixes $ for strings, # for floats, and nothing for integers.

Very little people on these forums obey any of the most basic things of the BASIC language (me included), and I think this is sad.

Props to you, Grasmann.

TheComet

Yesterday is History, Tomorrow is a Mystery, but Today is a Gift. That is why it is called "present".

Back to top

Profile PM Email Website

Kevin Picone

23

Years of Service

User Offline

Joined: 27th Aug 2002

Location: Australia

Posted: 20th May 2013 04:42

Link

Quote: "1) Can I suppose that my piece of code will be handled faster than now by my cpu?"

Well yes, with a healthy side of caution. It's no secret that the code generated from even your average C/C++ compiler will be faster than the Dbpro equivalent. But the question is far more complex than just a yes / no response can really answer. Since certain types of code fragments would benefit more than others.

A couple that come to mind could be routines that build/modify mem blocks, or functions that do lots of vector math, string / array handling among other things.

if you had a DBPRO function that draws to a mem block to create dynamic/procedural image for example. Then the inner loop is likely to be a bunch of Peek / Pokes (ie. WRITE MEMBLOCK DWORD) where a routine to fill a span could look like this.

eg.

+ Code Snippet

   For SpanLP=0 to Width-1
        Write Mem Block MyMemBlock,PixelAddress, MY_RGB_COLOUR
        PixelAddress=PixelAddress+4
   next

A naive port of such a routine to C might look like this..

+ Code Snippet

   for (SpanLP=0; SpanLP<Width-1; SpanLP++)
   {
        // just assume this is the same function.. 
        dbWriteMemBlock(MyMemBlock,PixelAddress, MY_RGB_COLOUR);
        PixelAddress=PixelAddress+4;
   }

The C compiler will make mince meat of such a loop structure, but we're still calling a function to write every 4 bytes of data. I dunno where DBpro handles error trapping, but I'm assuming inside the operation functions. So there's still a lot of dead weight in such a routine. Assuming we know the mem block exists and our read/write locations are legal. Then using a pointer would be better solution.

So if we replaced the Write Mem Block call with a pointer we'd get a version of the routine that far more efficient again.

+ Code Snippet

 
   unsigned long PixelAddress= (unsigned long)(dbMemBlockPointer(MyMemBlock) + PositionInFrameBuffer); 

   for (SpanLP=0; SpanLP<Width-1; SpanLP++)
   {
        *PixelAddress++ = MY_RGB_COLOUR;
   }

Still lots of loop overhead compared to data written, but removing the function call makes the result is a lot leaner than the DBpro original.

So to really harness the benefits of the moving Dbpro code across to C/C++, the user would have to be willing to strip out all the redundancy they can.

Mobile Platforms Are Coming

Back to top

Profile PM Website

Sorry your browser is not supported!

DarkBASIC Professional Discussion / Transform a piece of code in a DLL = better performance?