Hi Andreas, I don't know that I want a whole spreadsheet, but it's not clear to me how a 5% overhead turns into wasting 25% of our time (3 months out of 12). Partly that may be because I'm not sure what an "incremental cost of [...] 5% on average" means either. Can you elaborate please?
Thanks, Steve On Wed, Jun 8, 2016 at 2:20 PM Andreas Hansson <[email protected]> wrote: > Hi all, > > It is worth remembering that the argument about “low" effort needs to take > long-term usefulness into account. Yes, the incremental effort may seem > small per commit, but if the incremental cost per ISA is 5% on average, > and the likelihood of that effort being useful long term is 20%, then > after one year we have effectively wasted 3 months of gem5 contributions. > That is 90 commits. > > We can of course debate these numbers (let me know if you want the > spreadsheet...), but let’s not fool ourselves. Keeping things around has > noticeable implications on the overall progress. > > AndreasH > > > On 08/06/2016, 17:11, "gem5-dev on behalf of Steve Reinhardt" > <[email protected] on behalf of [email protected]> wrote: > > >On Wed, Jun 8, 2016 at 8:12 AM Andreas Sandberg <[email protected] > > > >wrote: > > > >> > > >> >Once the bar for reaching this point is raised by adding the steps of > >> >determining that gem5 *used to* support the ISA of interest, finding > >>and > >> >extracting the old revision that still had that support in it, and very > >> >likely needing to do who knows how much work to bring the ISA support > >>back > >> >in sync with the head of the repo before being able to reasonably make > >> >further enhancements, then the likelihood of anyone crossing that > >> >threshold > >> >is going to be dramatically lowered. > >> > >> You raise a valid point. However, I don¹t completely agree with your the > >> conclusion. > >> > > > >Hi Andreas, can you elaborate? I don't see anything you're saying that > >disagrees with what I think I said. > > > > > >> For complex work, say reworking register interfaces (e.g., Nathanael¹s > >> patch), modifying every single ISA adds a significant development > >> overhead. > > > > > >Yes, I didn't say that incrementally maintaining all the ISAs is always > >easy. My point is that, first, however much effort was required of > >Nathanael, the effort required for someone else to come back later, > >identify his change as one that needs to be applied to a defunct ISA, > >reverse engineer what he did, and then apply it, is going to be greater; > >and second, that greater effort, multiplied by the number of such changes > >that accumulate, will significantly reduce the likelihood that anyone ever > >does bother to resurrect an ISA, compared with the smaller effort of > >taking > >a functioning but incomplete ISA and addressing the gaps. > > > > > >> There is also a very real cost associated with having to > >> re-compile gem5 test all of the ISA/Ruby configuration we ³support". > > > > > >Yes, I didn't mean to imply that there weren't other costs. Your > >solutions > >below are some of the things I was thinking of when I said "some of the > >issues raised here could be addressed in other ways". > > > > > >> There > >> are two things we could do to improve the situation without completely > >> retiring ISAs: > >> > >> * Improved build system reuse. We could significantly shorten the > >> build/test cycle by only compiling device models and the core framework > >> once instead of for each ISA/Ruby configuration. > >> > >> * We should get rid of long tests for unsupported ISAs and make the > >> remaining tests functional only (i.e., not diff stats or out files). > >>This > >> would make stat refreshes (which pretty much every single non-trivial > >> change requires) much more manageable. I¹m planning to do similar things > >> for some of the ARM tests that are more functional in nature. > >> > >> > >> >Which leads to #2: Basically the only way you win by retiring code is > >>if > >> >that code is never resurrected. I'd say the lower bound on the cost of > >> >resurrecting the code is the same as the incremental cost of keeping > >>the > >> >code alive, and that's a very optimistic lower bound. In practice, > >>whoever > >> >faces the task of resurrecting the code won't know which past changes > >> >actually broke things, won't be the person who made those changes and > >> >thus, > >> >once the guilty changes are identified, will have to reverse-engineer > >>them > >> >to see how to apply them to the old ISA, and will be faced with the > >>task > >> >of > >> >fixing a number of things en masse rather than one at a time. In > >>addition, > >> >there's a good chance that someone considering taking this on is new to > >> >gem5 and unfamiliar with the code to begin with, unlike the person who > >>is > >> >committing patches and could perform the incremental updates. > >> > >> In that case, we Alpha would still be a candidate for removal. The > >> likelihood that someone will ever need it for research seems very low > >>and > >> having to resurrect it seems extremely unlikely. A simulator such as > >>SimH > >> seems more suitable for what can only be described as retro computing > >> (which I enjoy, but it¹s not gem5). > >> > > > >Yes, I don't dispute that Alpha looks like something we should rationally > >retire. For sentimental reasons I'd hate to see that happen, but I won't > >claim they are much more than that. Though perhaps there is pedagogical > >value in providing architecture students, who might not download SimH on > >their own, the opportunity to look at the ISA and weep for what could have > >been... > > > >>It would also be nice to keep in mind that some of the issues raised here > >> >could be addressed in other ways. For example, with respect to user > >> >expectations, there is already some documentation on the wiki about the > >> >level of support for various ISAs: > >> >http://gem5.org/Architecture_Support > >> >http://gem5.org/Status_Matrix > >> >Regardless of the outcome here, it would be good to keep that > >>information > >> >up to date and maybe feature it more prominently so that new users are > >> >aware of it. Perhaps less-supported ISAs could print a warning and a > >>link > >> >to these pages when they are used. > >> > >> Updating these pages is definitely something we should do regardless of > >> whether we retire existing ISAs or not. We should make sure that both > >>the > >> build system and the generated binary print a warning if a user wants to > >> use one of the unmaintained ISAs. This should help in setting > >> expectations. > >> > > > >Yes, I agree with this too. > > > >Steve > > > > > >> > >> //Andreas > >> > >> IMPORTANT NOTICE: The contents of this email and any attachments are > >> confidential and may also be privileged. If you are not the intended > >> recipient, please notify the sender immediately and do not disclose the > >> contents to any other person, use it for any purpose, or store or copy > >>the > >> information in any medium. Thank you. > >> > >> _______________________________________________ > >> gem5-dev mailing list > >> [email protected] > >> http://m5sim.org/mailman/listinfo/gem5-dev > >> > >_______________________________________________ > >gem5-dev mailing list > >[email protected] > >http://m5sim.org/mailman/listinfo/gem5-dev > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
