Hi all, Just to add on to what everyone else has said. While gem5 is single threaded, the common use case is to run many different experiments with gem5 (e.g., many workloads, many system configurations). Therefore, commonly, you can use all of your cores by running many different gem5 instances. It's weak scaling, but I've found that in my research, that's the common case anyway.
Cheers, Jason On Sat, Aug 31, 2019 at 10:46 AM Eliot Moss <[email protected]> wrote: > On 8/31/2019 12:42 PM, Abhishek Singh wrote: > > Hi yuan, > > Gem5 is a single thread application. So there’s no way to speed up gem5 > with increasing number of core. > > I'll just add that doing parallel simulation, especially if timing is > involved, > requires a lot of synchronization. One can imagine doing optimistic > run-ahead, > possibly tuning the degree of optimism dynamically, etc., but I think such > a > system would be pretty complex, and it's not clear how much benefit you > would > get after dealing with the overheads. Anyway, IMO it would require > designing > a system that way from the start. Still, I admit I am not familiar with > the > low-level scheduling "guts" of Gem5, which is a key part that would need to > change. However, to do well, one would need to know how different > components > depend on various pieces of state in order to determine what might run in > parallel, etc. > > Regards - Eliot Moss > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
