I disagree as far size is concerned :
even when compressed, the opk is around 284ko compared to 1.1Mb so it's almost 4 four times smaller.
But i agree that speed isn't going to be much affected, since it mostly relies on a dynarec anyways.
Thank you for answering my shit posting tho
Debug symbols shouldn't affect the runtime speed of a program, at least very very little. Only way it could slow things down is the increased size of the binary, but the binary should be mmap'd in and only the sections of the executable actually read and executed should be paged in from disk so I doubt that'd affect load time of binary either. Or if the linker doesn't put all the symbols together so that they don't increase # of page faults when executing code. Perhaps Dmitry would find it a good idea to release the binary stripped, but yeah compiler flags will do very little I think you'll find, at least on MIPS platform
They will likely only bloat the code even further than MIPS code already is, so less of it fits in L1 cache.
As for GCC6, I have tried a build using it not long ago, both with and without LTO, and found no measurable difference in performance, from brief tests. GCC6 also would eliminate ability to use MXU SIMD instructions, as the MXU patch set would need to be ported.
Only thing that will speed it up I think is if either the recompiler gets a 2nd or 3rd pass added to optimize the generated code (eliminating load stalls and dead code, peephole optimization). That and optimization of software poly rendering, which will be a ton of work for probably a small 5-10% overall speedup if I had to guess. The first is beyond my area of expertise (would be Dmitry if anybody), the latter I already have routines for written on paper, but that's a long way from actual implementation. Another thing that'd help is if a future firmware update increases page size from 4KB to something larger, decreasing # of TLB misses.
I am in the middle of writing an MXU-optimized screen blitter and IPU HW scaling implementation. Using the HW scaler will actually slow things down for the vast majority of cases, as more needs to be rendered when downscaling, rather than just skipping pixels/lines that SW downscaler currently ignores. The MXU screen blitter will provide a small speed increase when using the existing SW scaler, but it will probably be unnoticeable, like 2%.
