Bitwise or operator versus logical or operator

View previous topic View next topic Go down

Bitwise or operator versus logical or operator

Post by LabRatAndy on Thu Jun 18, 2015 10:02 pm

I've recently being doing some profiling of openBVE to try speed up the loading of routes. When I noticed that one of the heavily called functions  vertex equality operator was using a bitwise (|) or operator to check equality (see code segment)
Code:
public static bool operator ==(Vertex A, Vertex B) {
if (A.Coordinates.X != B.Coordinates.X | A.Coordinates.Y != B.Coordinates.Y | A.Coordinates.Z != B.Coordinates.Z) return false;
if (A.TextureCoordinates.X != B.TextureCoordinates.X | A.TextureCoordinates.Y != B.TextureCoordinates.Y) return false;
return true;
}

However, should this be the logical(||) or operator? As this would not speed up the process very slightly? As logical(||) or does "short circuiting" where by the first compareson is done should it be true then the rest need not be done. Also given that logically if any one of the values is not equal then the vertex cannot be the same.  I don't really see why it is being used in this case or am I missing something here?

LabRatAndy

Posts : 95
Join date : 2011-08-29

Back to top Go down

Re: Bitwise or operator versus logical or operator

Post by leezer3 on Sat Jun 20, 2015 12:44 pm

Interesting question.

I suspect this will depend heavily on how the C# runtime is optimised internally; In C/ C++ bitwise operations are very marginally faster (Something to do with hardware registers on the CPU, not sure exactly what mind Razz ), and this may well translate to C# speed.
http://blog.typps.com/2007/10/bitwise-operators-in-c-or-xor-and-not.html

Loading speed IMHO isn't the issue, but rather framerates. I've looked into this, but unfortunately the only real way to solve this is to rewrite the whole renderer and parts of the game engine from scratch, and that's nowhere near my level. A brief technical analysis:
At the minute, the whole game, including the renderer is run inside the single MainLoop thread.

This was the result of my last set of profiling on the mainloop:
(Plymouth Route + Dinmore Manor- Complex plugin running various animations and a steam engine simulation, a relatively minimal set of animated world objects, primarily signals and a few large conglomerate objects):
OpenGL system calls (Rendering faces): ~20%
JIT Object loading ~20%
3D exterior calculations ~10%
Updating world animated objects ~5%


The OpenGL implementation is where there is most room for improvement-
Each time a face is rendered (In general terms, this is a single [MeshBuilder] statement, within an object, although the sim will combine wherever possible), the RenderFace function is called, which starts off an entirely new GlBegin/ GlEnd chain.
Faces without transparencies or lighting are wrapped within OpenGL Call Lists wherever possible, but otherwise are plain OpenGL statements. (Wrapping everything else in Call Lists increases the framerate a little, but causes visual issues)

It really wants rewriting with VBOs, which would probably speed it up by an order of magnitude.


FWIW, I've actually got a version I've been playing with, which replaces Tao with OpenTK, which is marginally faster, but nothing really useful.

Cheers

Chris Lees

http://www.bvecornwall.co.uk

leezer3

Posts : 895
Join date : 2011-08-23

http://www.bvecornwall.co.uk

Back to top Go down

Re: Bitwise or operator versus logical or operator

Post by Quork on Sat Jun 20, 2015 1:33 pm

I guess the "easiest" (and still very hard) way to increase performance would be to switch to using an external 3D engine. The dev team of LokSim3D e.g. is aiming for this in the long run, but it still is much work.
avatar
Quork

Posts : 1078
Join date : 2012-05-05
Age : 25
Location : Hofheim a.T., Hessen (Hesse), European Union

Back to top Go down

Re: Bitwise or operator versus logical or operator

Post by leezer3 on Sat Jun 20, 2015 11:42 pm

It's not so much the 3D engine, as the game engine itself as a whole; They're very much intertwined.

Find yourself a copy of a very basic route (BVE2 era), and run it with a GPU load monitor program active.
You'll find that this will quite happily max out the GPU if you max out the AA/ AF setttings.

Now load a complex route, and look at the GPU load again.
You'll notice that even with the AA/ AF settings maxed out, you're only sitting at ~30% GPU load.

Why is this?
Using a single loop thread to run *everything* means that if one function is slow, it effectively blocks the next from updating until it's finished.
Graphics card usage is lower the more complex the scene is because it's actually spending more time opening and closing the graphics card and waiting for the renderer to finish calculating the next frame- Modern graphics cards are capable of throwing around huge amounts of data, but opening and closing them takes a significant chunk of time Smile

Cheers

Chris Lees

http://www.bvecornwall.co.uk

leezer3

Posts : 895
Join date : 2011-08-23

http://www.bvecornwall.co.uk

Back to top Go down

Re: Bitwise or operator versus logical or operator

Post by Quork on Sun Jun 21, 2015 12:05 am

I'm not sure I'm getting all the technical detail, but over all, I think I get the problem. Thanks for clearing that up.

Does this mean a major performance boost would be possible by splitting that main loop thread into a "graphics loop" thread and an "everything else loop" thread?
avatar
Quork

Posts : 1078
Join date : 2012-05-05
Age : 25
Location : Hofheim a.T., Hessen (Hesse), European Union

Back to top Go down

Re: Bitwise or operator versus logical or operator

Post by hkmtrhah on Sun Jun 21, 2015 3:38 pm

At least a little bit, and not "an everything-else thread" but many threads, and using ThreadPool or sth similar that makes threads be re-usable, afaik.

Such difference may also be seen on a quite famous bus simulating game, OMSI. You'll see the FPS drops quite much when enabling "less threads mdoe".
avatar
hkmtrhah

Posts : 34
Join date : 2013-06-19
Location : Hong Kong

http://about.me/hkgsherlock

Back to top Go down

Re: Bitwise or operator versus logical or operator

Post by Quork on Sun Jun 21, 2015 3:50 pm

Well, my guess was that in OpenBVE graphics are the most challenging stuff and thus separating the rest wouldn't do much good (besides probably higher physics FPS, but imho that's not as critical with a railway simulation, even as low as 20 still works neatly, space shooters are something different of course), but that's just wild guessing by someone with little knowledge in the matter.
avatar
Quork

Posts : 1078
Join date : 2012-05-05
Age : 25
Location : Hofheim a.T., Hessen (Hesse), European Union

Back to top Go down

Re: Bitwise or operator versus logical or operator

Post by LabRatAndy on Sun Jun 21, 2015 5:11 pm

Chris, I know that loading time is not really a massive issue per say, it was just that I noticed that on my new albeit very modest laptop, loading times compared my old (11 year old) were almost the same regardless of the increase in computing power. Although I get this might just be down to delay in reading from a hard drive?
Yes I understand that openBVE doesn't really use modern 3d rendering techniques, although I did think the opitimseobject function tried to implement basic vertex buffer arrays though quadstrips and trianglestrips(I might be wrong though I'm no expert on 3d graphics rendering).
I would however agree slightly with you Quork that using 3d engine like Ogre3D might make more sense than continuing to use or rewrite a renderer from scrach.
I also can see how using more than 1 thread could speed up the game loop using a simulation update loop and a rendering loop, however the interaction between the loops would need to be closely managed.

LabRatAndy

Posts : 95
Join date : 2011-08-29

Back to top Go down

Re: Bitwise or operator versus logical or operator

Post by Sponsored content


Sponsored content


Back to top Go down

View previous topic View next topic Back to top


 
Permissions in this forum:
You cannot reply to topics in this forum