Here lies JitIL, a long-time CPU engine of Dolphin. #1023
Conversation
waddlesplash
force-pushed
the
kill-jitil
branch
2 times, most recently
from
d3c44a7
to
0ff0f80
Compare
|
You will need to also remove the references to JitIL from the VS filter file |
Rationale for removing it:
* It was only faster than Jit64 on 32-bit x86 which is no longer
supported and has been removed
* After the flag optimization landed, JitIL did not get it and as
such is broken on >80% of games (according to JMC4789).
waddlesplash
force-pushed
the
kill-jitil
branch
from
0ff0f80
to
cabe92e
Compare
|
@lioncash done. |
|
Need to update the Android UI to remove references to it as well. |
|
The rationale for keeping it was that it could help find bugs on JIT. |
|
@Sonicadvance1 will do. @archshift indeed, but now since nobody seems keen on maintaining it and it doesn't boot the vast majority of games I don't see any reason to keep it around. |
|
Ping @JMC47. As the main tester for things, is JITIL still useful for finding bugs in the JIT or no? |
|
I like the JitIL approach. It's a good start which would allow you to do optimisations which are hard to impossible in jit64. But it needs lots of work and maintenance to reach it's full potential, which it just isn't getting. The only compelling argument (apart from testing) I can see for keeping it in the tree is that if someone did want to start maintaining it, re-merging it would be hard. (And that's not the best argument.) |
|
Kind of sad to see it go tbh, but recently it's been lagging behind and nobody seems really interested in maintaining it. The ideas behind it are great and imo I think it could potentially have been better than our current JIt in many ways, but it always lacked manpower to fix regressions. So +0.5 from me. |
|
I am half interested in maintaining and improving JitIL myself, but I don't know if I will ever get around to doing so. |
|
Unless someone is planning on making it boot games again, I don't see why it shouldn't be removed. Should we wait a while? Should we see if anyone is interested? Flagsopt still has a few games broken on JIT, too. FWIW, I was misunderstood. Flagsopt was implemented on JITIL, it just doesn't seem to be working well. |
|
@magumagu think you could have a look at the issues in JitIL? |
|
Lets not rush to remove this. It's not currently hurting the rest of our code base. I would like some time to think about if it's worth keeping/fixing/improving. Then perhaps we should talk about this in our next monthly progress report, see if someone appears to maintain it. How about a deadline of halfway through October before removal? |
|
Maybe remove the option from the UI for users; since right now it's an absolutely huge liability. |
|
I think that would remove incentive to even consider bringing it back to a more operational state. |
|
I don't want someone to maintain it just enough so we can keep it in and then promptly drop it again. I want a commitment to maintenance, and if nobody has been doing that now, I don't see why it would start. It's not like a revert is particularly hard to do if we want the code back -- it's all still there in the git history. |
|
The problem with reverting is that it becomes hard to git blame. A bunch of It also (like removing the UI option) kills most of the incentive to get it Scott Mansell On 8 September 2014 17:30, Jasper St. Pierre notifications@github.com
|
|
I wish less were predicated on the limitations of git blame - not only this but formatting changes. I don't even have an easy way, when blaming, to move to the version of the file before the last (frequently unrelated) change to a given line, although apparently |
|
We commonly make giant changes and refactors to the source code like the removal of Src/, and I can still use git blame just fine. We shouldn't delete garbage crummy code if it's garbage crummy code just so someone can spend 5 less seconds figuring out who was responsible for the garbage crummy code they want to delete. The incentive to fix JITIL has been there for at least half a year, and nobody has shown up. Why would they be incentivized now, and who will do it? |
|
FYI, you can copy/paste the revision of who brought it back, and use |
|
So, Turns out JitIL is 100% broken in current master. I like JitIL. So I'm going to spend some time fixing it. |
|
Well, @phire seems to have fixed it, for now anyway, and it apparently has merit that I didn't know about. Closing this (for now at least). |
|
I'm not sure JITIL worth maintaining at this point... Jit64 has become much more mature since JITIL was written, JITIL's floating-point handling code needs substantial changes now that we have a better understanding of how the Gekko FPU works, the most important issues in terms of CPU optimizations in the near future aren't the sort of things JITIL actually helps with, and it seems like I'm the only person who really understands how JITIL works. I've also learned a lot about software development since I initially wrote JITIL: the fact that JITIL is a fork makes it much more difficult for it to get anywhere. If someone is actually interested in reviving JITIL, the right approach is probably to kill the existing code and redo it incrementally on top of JIT64. A patch introducing an IR almost identical to the PPC instruction set (same operations, abstract registers) plus a simple register allocator would be large, but probably still small enough to merge without forking the JIT, and it would mostly use the existing well-tested codepaths. With that basic framework in place, we could start making the IR for some important operations like integer arithmetic and branches more abstract, and adding some cross-instruction optimizations. |
|
I'm not sure JITIL is worth maintaining at this point either. My interest in maintaining JITIL right now mostly involves the possibility of either progressively transforming it's IR to something closer to what we need or Straight ripping the IR out and plopping a new one in. I feel like such an approach could be easier than starting from scratch again, or doing it incrementally (But I only started looking at the code seriously last night.)
This is actually happening right now. Fiora's Carry optimisation patches (see #1021) are pushing PPCAnalyst to the point where it is treating the powerpc instruction stream (and the InstructionInfo data) as a rudimentary IR. Carry optimization is exactly the kind of optimisation that should have been implemented in JITIL. Theoretically, the code would probably look cleaner than what is getting implemented in Jit64, with it's convoluted instruction re-ordering and instruction merging. Fiora's Carry optimisation PR and other PRs like it are actually the most compelling reason for ditching JITIL. I may be putting some maintenance into JitIL, but the removal argument is not over. |
|
Well, in that case... |
|
Yes. Leave it open. This could be a long drawn out argument. The fact that JitIL is not going to survive in it's current state is certain. The question is does it get transformed, or deleted (and when exactly should it be deleted?) |
|
I think everybody agrees that the long-term goal is to merge the strategy and ideas of JITIL with JIT64. Having watched Fiora's changes, yeah, JIT64 is growing to the point where it needs an IR. I don't think we need to keep around the JITIL code because of git blame simply so that we can merge it in. I've also had users / developers get confused -- "wait, JITIL is the fancy new experiemental JIT, right? Why are you working on JIT64? Shouldn't I be working on JIT64?" Killing JITIL is a step towards progress, I feel. Users who need JITIL because games don't work under JIT64 now have to get angry and file bugs and we have to fix JIT64 and make it better and stronger. |
Rationale for removing it: