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<unsigned long long>. 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
