Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Areas of interest for new linux developers
#21
Some modification will be surely merged but free time is very scarce Wink

AIO isn't important. It would be very easy to replace it with a standard IO.
Reply

Sponsored links

#22
Hehe, free time is precious, indeed. Going through the code and also glancing at the current progress with the OSX side of things: a lot of functionality that comes now into the codebase (e.g. threading) is again very OS-dependent so soon you would have "Mac" folders next to the "Linux" and "Windows" ones. Going trough them I see that there is a lot of code that revolves around file access, mmaps, threading and the usual things that libraries like Boost are perfect in handling. I don't know the team's stance on this (and I am not a preacher of Boost or anything) but wouldn't the inclusion of such a library have its best time now? Just before everything becomes more portable and arch-/platform-independent? A lot of those files in the "Linux" and "Windows" folders now use OS-dependent two-liners. I would like to help here since I regard this as a fundamental thing to push pcsx2 forward towards that goal. I could start from Linux 32-bit builds and remove the "Linux" and "Windows" folders with equivalent Boost (or any other lib) functionality in the commons-part. First the easy things that are unlikely to brake stuff (like file access etc.) and removing AIO in the process as well. What are you/the team thinking?
Reply
#23
From an old PCSX2 dev: http://forums.pcsx2.net/Thread-blog-C-ex...5#pid79305

On my side, I'm afraid of packaging issue (32 bits compilation on 64 bits, new library transition) + additional compilation time. Honestly I'm not sure the boost big bertha is the best solution. I would ask others opinions.

Note AIO is just a minor optimization. It might even work without any implementation.
Reply
#24
By the way it is still possible to use portable code only for OSX. And later extend it to others OS if it is fine.
Reply
#25
I think the best solution for now is to wait until all the important 64bit-changes have been done. Since you port it and there are two other guys hitting at an OSX version I will just wait until the branches converge more or less. I guess it makes no sense to open up another keg. Then I would definitely chime in again.
Reply
#26
On https://github.com/PCSX2/pcsx2/blob/mast...eLists.txt why are the optimizations flags separated like that. That's almost -02 for gcc

-fauto-inc-dec
-fcompare-elim
-fcprop-registers
-fdce
-fdefer-pop
-fdelayed-branch
-fdse
-fguess-branch-probability
-fif-conversion2
-fif-conversion
-fipa-pure-const
-fipa-profile
-fipa-reference
-fmerge-constants
-fsplit-wide-types
-ftree-bit-ccp
-ftree-builtin-call-dce
-ftree-ccp
-ftree-ch
-ftree-copyrename
-ftree-dce
-ftree-dominator-opts
-ftree-dse
-ftree-forwprop
-ftree-fre
-ftree-phiprop
-ftree-sra
-ftree-pta
-ftree-ter
-funit-at-a-time


-O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging.
-O2
Optimize even more. GCC performs nearly all supported optimizations that do not involve a space-speed tradeoff. As compared to -O, this option increases both compilation time and the performance of the generated code.

-O2 turns on all optimization flags specified by -O. It also turns on the following optimization flags:

-fthread-jumps
-falign-functions -falign-jumps
-falign-loops -falign-labels
-fcaller-saves
-fcrossjumping
-fcse-follow-jumps -fcse-skip-blocks
-fdelete-null-pointer-checks
-fdevirtualize
-fexpensive-optimizations
-fgcse -fgcse-lm
-finline-small-functions
-findirect-inlining
-fipa-sra
-foptimize-sibling-calls
-fpartial-inlining
-fpeephole2
-fregmove
-freorder-blocks -freorder-functions
-frerun-cse-after-loop
-fsched-interblock -fsched-spec
-fschedule-insns -fschedule-insns2
-fstrict-aliasing -fstrict-overflow
-ftree-switch-conversion -ftree-tail-merge
-ftree-pre
-ftree-vrp

Coudn't we just define -02 ? Or at least enable some inline functionality that currently its not defined?
Reply
#27
A long time ago, PCSX2 wasn't stable with all gdb optimization. So O2 was replaced with nearly all optimization minus a couple one.

I'm very close to get back to O2 again. However it would help a lots if someone find optimization that are not activated.
1/ Either flags are replaced with 02 + -fno-... flags
2/ Either we completely swtich to 02 (minus the fact that a couple of flags are disabled like strict aliasing).

Others cmake files that are impacted
Quote:https://github.com/PCSX2/pcsx2/blob/mast...eLists.txt
https://github.com/PCSX2/pcsx2/blob/mast...eLists.txt
Reply
#28
-finline-small-functions
-findirect-inlining
-fpartial-inlining

Namely those are missing.
I would opt for 1) i guess Clang would be happier as well
Reply
#29
https://scan.coverity.com/users/sign_in

Could we "attach" this to PCSX2?
Reply
#30
Actually maybe it will be safe to enable O2 instead. I don't think inline could break code, actually it might fix some compilation issue (failed to inline some functions).

For coverity, I will discuss with some friends that use it. However I'm afraid that is pretty expensive and last but not least that it requires a test suite.
Reply




Users browsing this thread: 1 Guest(s)