Hi Arthur, I think it’s a great idea. It sure seems like quite a bit of work but I’m pretty sure it will pay off in the long run!
I guess in addition to the checkpoint themselves, it would be good to provide metadata about how they have been created (compiler version + flags, Simpoint options, simpoints weights, etc). For upgrading checkpoints when needed, there is the util/cpt_upgrader.py script but I don’t know if it is up-to-date. Thanks, Nathanael From: Arthur Perais via gem5-users [mailto:gem5-users@gem5.org] Sent: Wednesday, March 17, 2021 11:47 AM To: gem5-users@gem5.org Cc: Arthur Perais <arthur.per...@univ-grenoble-alpes.fr> Subject: [gem5-users] checkpoint/simpoint repository Hi all gem5 users, A while back, I had contacted the SPEC committee to ask what their stance was about sharing gem5 SPEC CPU checkpoints (I am not aware of any public repo of gem5 checkpoints but I might be wrong!) tl;dr : checkpoints can be shared as long as it is behind a password, and the password is only given to people who have a SPEC CPU 2kX license (this can be verified by emailing i...@spec.org<mailto:i...@spec.org>) This is the exact answer that I got (I am quoting verbatim) : 1. The checkpoints distributed shall not contain enough code to produce a compliant SPEC CPU 2017 run. 2. The whole checkpoint process must follow the Fair Use rules for Academic/research usage: https://www.spec.org/fairuse.html#Academic 3. Arthur and his team [or a volunteer] shall maintain the checkpoints and let the SPEC CPU committee know of the location which they will be hosted from. a. The SPEC CPU committee shall also be given ability to check on checkpoints hosted and shared. b. The link shall be protected by a password or similar authentication method such that anyone that has the link to the location cannot automatically download data which may contain SPEC CPU 2017 code and/or executables. 4. The person/entity receiving the checkpoint may not distribute it beyond themselves and/or beyond the scope of the immediate need for the checkpoint. I wanted to start a discussion about whether there is interest in doing this (not only for SPEC, but SPEC is a big one). On the one hand, checkpoint format has been changing often and so checkpoint occasionally break. Moreover, certain features may require generating new checkpoints anyway (adding model specific registers maybe?). On the other hand, since many researchers generate their own checkpoints/simpoints, there is a lot of variability (maybe a given mechanism is not that interesting if I compile with O3 but works great with O2), and having some "golden" checkpoints for usual workloads may help homogenize gem5 research. Since gem5 has releases, maybe tying "golden" checkpoints to releases would be a good enough workflow for many users. Cheers, Arthur
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
