Started by DrSuperGood, February 20, 2017, 07:27:19 AM
0 Members and 1 Guest are viewing this topic.
QuoteFor fillbox, it is still a bad idea.
QuoteFor text, it depends on the processor. Conroe prefers the assembly, ivybridge does not.
QuoteI find it a little odd to knowingly reduce performance on older processors when the people using them will be the ones for whom performance is already more of an issue than on more modern machines.
Quote from: DrSuperGood on February 26, 2017, 07:48:16 PMThis is a GCC problem though. MSVC last I checked (just updated to 2015 update 3 so might have changed) generated assembly for the low level similar to the inline assembly (rep stos) so should perform equally, if not better on older processors as I added alignment.
Quote from: DrSuperGood on February 27, 2017, 01:21:00 AMIt is also odd to knowingly reduce performance on newer processors when you know that more and more people in the future will be using them. My justification is entirely based on minimizing future development work, since naturally user metrics will shift towards the processors that it runs better on and away from the ones it runs worse on. If we prefer older processors for speed then it means that some time in the future another such topic as this will be created arguing about the code performance and it will have to be changed to what we could change it to now.If Pentium 4 compilation is possible even the old processors will gain somewhat with speed. Just newer processors will have the biggest gains.
QuoteUnfortunately, that Microsoft does better is only useful for Windows users at best. I'm not even sure if that is a majority of our users anymore.
QuoteYour code in endiancheck is anyway assuming that the processor has a swap command to swap low and high word. Otherwise a 16 bit shift and an or is not neccessarily faster than just two copy commands. Since the only platform for now is the old PowerMac and Amiga target using big endian, I would rather suggest the compiler to use the simple copy code and leave optimisations to the compiler.
QuoteAlso other parts of simutrans uses SIM_BIG_ENDIAN for endianess check. Then the code should do this too.
QuoteThere is LITTLE_ENDIAN in simconst.h (new) and SIM_BIG_ENDIAN in sim_types.h (since ages). This should be unified somehow.
#if defined(__BYTE_ORDER) && __BYTE_ORDER == __BIG_ENDIAN || \ defined(__BIG_ENDIAN__) || \ defined(_BIG_ENDIAN) || \ defined(__ARMEB__) || \ defined(__THUMBEB__) || \ defined(__AARCH64EB__) || \ defined(_MIBSEB) || defined(__MIBSEB) || defined(__MIBSEB__) \\ defined(_M_MPPC) || defined(_M_PPC)// It's a big-endian target architecture#define SIM_BIG_ENDIAN#elif defined(__BYTE_ORDER) && __BYTE_ORDER == __LITTLE_ENDIAN || \ defined(__LITTLE_ENDIAN__) || \ defined(__ARMEL__) || \ defined(__THUMBEL__) || \ defined(__AARCH64EL__) || \ defined(_MIPSEL) || defined(__MIPSEL) || defined(__MIPSEL__)// It's a little-endian target architecture#else#error "I don't know what architecture this is!"#endif
QuoteAfter finishing this, maybe it should go to technical documentation, before the next optimisation round circa 2020?