Patch: Improved acceleration for road vehicles [In trunk]

[Thief^]

If you cast to a pointer to a derived type (with no other types derived from it), the compiler will normally inline virtual functions then too. It assumes that if you have cast to that type, it must be that type, and as there are no types that inherit from it it is safe to inline.

[Terkhen]

Since the function is templated, I'm using a cast to the templated type instead of letting the compiler use virtual functions. I get a performance boost doing this, but the functions are not inlined. I suspect that the functions I need to inline are called without using vtables (hence the performance improvement), but the compiler still can't inline them (if they appear at gprof it means they are not optimized into something else). I don't know why using the templated type is not enough for inlining the functions, though

Anyways, I finally realized how to force the compiler to inline these virtual functions: removing them. I just commented out the virtual functions at the parent class (AcceleratedVehicle). Since the child classes still implement all methods, the code works. The resulting code for UpdateTrainSpeed is even faster than trunk, requiring only 83.2% of the time to execute (I'm using TIC TOC again, check this thread to see my method). This improvement over trunk code is caused by optimizations I have implemented at the various parts of the acceleration code (I have checked these results three times, feel free to check my data as I could have some mistake).

I know that using virtual functions at the parent class is the right way of forcing all child classes to define them. But since this optimizes a key part of the code and the code still fails at compile time if any of these functions is not defined at the child class, I think that removing them from AcceleratedVehicle is for the best. Right now the virtual functions are commented at the parent class, but I'd like to know which would be the best way of documenting that all children of this class must have these functions defined.

You can find the optimized v16 version at the first post.

[Terkhen]

I have uploaded a part of the patch (train realistic acceleration code reorganizations and optimizations) to flyspray: http://bugs.openttd.org/task/3524

It would be very helpful for the Improved acceleration for road vehicles patch if you help testing the patch found at the flyspray task: any game involving trains with realistic acceleration on will do. Report any bugs or problem to the flyspray task.

Edit: This part of the patch is now in trunk.

[Terkhen]

This feature (except some bits) is now in trunk. Happy testing!

[ostlandr]

Hooray! I saw this in the nightlies list. Great work! Gotta go try it out now.

This feature (except some bits) is now in trunk. Happy testing!

[andythenorth]

This feature (except some bits) is now in trunk. Happy testing!

Awesome

I'll check it with HEQS soon!

[Kogut]

- Yet another thing to do in AI

[Terkhen]

andythenorth: I kept using HEQS for testing. The articulated vehicles need some tweaking (they seem to need more tractive effort), but the standard ones work fine. Thank you for your help with this patch

Kogut: I wouldn't worry too much about the standard vehicles: as always, the newest road vehicle is always the best one.

Here is one of the missing bits from the original code: power, weight and tractive effort support for callback 36 (mind the p1). It should work, but it needs some testing before commiting it. A NewGRF to test these callbacks will be welcome

150-callback_36_support.diff

(4.09 KiB) Downloaded 92 times

A note: I have seen that some existing road vehicle sets have unset values for some of their vehicles: these vehicles will move really slow if realistic acceleration for road vehicles is on.

EDIT: Air drag was commited in r20303, and support for CB36 was commited in r21058 and r21100. Since then, every feature that was once present in this patch has made its way to trunk. I really appreciate the help I had while developing this feature. Thank you!