[gem5-users] Re: Gem5 stuck when simulate C++ workload in SE mode
Hi Victor, No, it won't because the random number generator that you seed with seedRandom is independent from the one you seed inside your program. seedRandom seeds random_mt declared in base/random.hh which is not accessible from inside your program as of the latest version of gem5. You can easily fix that: First, go to kern/linux/linux.cc:130 (inside devRandom()) and replace "random.random(0, 255)" with "random_mt.random(0, 255)". Second, read /dev/random inside your program to seed your internal pseudo-random number generator. This seed will be determined using random_mt which is itself seeded by yourself using seedRandom. Alternatively to the first step, you can define a python binding in python/pybind11/core.cc (or update the existing seedRandom binding) to seed the random generator currently used by devRandom(). This is a bit more work but it will guarantee that the value you get from /dev/random does not depend on what happens in the rest of the simulator. Gabriel ___ 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
[gem5-users] Re: Gem5 stuck when simulate C++ workload in SE mode
Hi Gabriel, I've followed the instructions you have provided but I'm still getting the same numbers on every gem5 run. The changes I made to se.py are the following. + from _m5.core import seedRandom seedRandom(int()) I'm producing random numbers in my program by seeding srand with time srand and rand. Shouldn't changing the seed I provide to the seedRandom function result in different numbers generated in each run of the program. Please correct me if my understanding is wrong. Thanks, Victor ___ 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
[gem5-users] Re: Gem5 stuck when simulate C++ workload in SE mode
Hi Gabriel, Thanks for your help. This way is much simpler than trying to get a true random generator in the C++ workload. Best, Duc Anh On Tue, 20 Jul 2021 at 15:40, Gabriel Busnot via gem5-users < gem5-users@gem5.org> wrote: > Indeed, gem5 is designed to be deterministic so all random number > generation should rely on a deterministically seeded random number > generator. This random number generator normally is 'random_mt' located in > src/base/random.cc. However not all random number generated in gem5 relies > on this generator, yet. > > Looking at syscall emulation implementations, it looks like a dedicated > random generator is used here for emulating a read to /dev/urandom: > src/kern/linux/linux.cc:126. You could replace "random.random(0, > 255)" with "random_mt.random(0, 255)" to use the main random > number generator. Not tested but should work. Then, you can seed random_mt > from your python script using "seedRandom(int())". seedRandom is > from the m5.core module. I personally like to use a --seed command line > option to set the seed more conveniently. > > Gabriel > ___ > 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 > ___ 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
[gem5-users] Re: Gem5 stuck when simulate C++ workload in SE mode
Indeed, gem5 is designed to be deterministic so all random number generation should rely on a deterministically seeded random number generator. This random number generator normally is 'random_mt' located in src/base/random.cc. However not all random number generated in gem5 relies on this generator, yet. Looking at syscall emulation implementations, it looks like a dedicated random generator is used here for emulating a read to /dev/urandom: src/kern/linux/linux.cc:126. You could replace "random.random(0, 255)" with "random_mt.random(0, 255)" to use the main random number generator. Not tested but should work. Then, you can seed random_mt from your python script using "seedRandom(int())". seedRandom is from the m5.core module. I personally like to use a --seed command line option to set the seed more conveniently. Gabriel ___ 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
[gem5-users] Re: Gem5 stuck when simulate C++ workload in SE mode
Hi Gabriel, It was indeed the output is stuck in the stdout buffer because the program ran too long. When I increase the >> 25 to >> 45 I can see it works fine. It was quite fast on the host, I just don't think it would be that slow on the simulator. I generate random numbers by std::random_device, std::mt19937, and std::uniform_int_distribution. and bound them inside the 64-bit range. However, the randomized number is the same between every invocation of Gem5, is this due to the deterministic property of Gem5? Best, Duc Anh On Tue, 20 Jul 2021 at 14:24, Gabriel Busnot via gem5-users < gem5-users@gem5.org> wrote: > Hi Duc, > > Having the print not displayed on screen does not necessarily mean that it > has not been executed. It could just have been stuck in stdout buffer which > was not flush because of an abnormal program termination. > > If you initialize you data with truly random and unbounded data, "number = > block.number[i] >> 25" could be as big as (2^(64-25)-1) which is... huge, > even taking the sqrt. > If you have not already done so, you should check that cap is not to big > in some cases and that the program takes a reasonable amount of time when > running natively on your host. By reasonable, I mean a couple of ms for a > less than a minute simulation on gem5. > > And as a side note, if you want to stress your caches, you can have a look > at the MemTest cpu in gem5. It is purposely built to generate back to back > memory accesses with controlled line sharing. > > Best, > Gabriel > ___ > 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 > ___ 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
[gem5-users] Re: Gem5 stuck when simulate C++ workload in SE mode
Hi Duc, Having the print not displayed on screen does not necessarily mean that it has not been executed. It could just have been stuck in stdout buffer which was not flush because of an abnormal program termination. If you initialize you data with truly random and unbounded data, "number = block.number[i] >> 25" could be as big as (2^(64-25)-1) which is... huge, even taking the sqrt. If you have not already done so, you should check that cap is not to big in some cases and that the program takes a reasonable amount of time when running natively on your host. By reasonable, I mean a couple of ms for a less than a minute simulation on gem5. And as a side note, if you want to stress your caches, you can have a look at the MemTest cpu in gem5. It is purposely built to generate back to back memory accesses with controlled line sharing. Best, Gabriel ___ 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
