Soon! https://gem5.atlassian.net/browse/GEM5-195
We're hopeful that in the next month or so all of this code will be public. Cheers, Jason On Fri, Apr 16, 2021 at 9:55 AM John Smith <jjsmith2...@gmail.com> wrote: > Will I also be able to run the GPU model in the FS mode ? > > On Fri, Apr 16, 2021 at 11:39 AM Jason Lowe-Power <ja...@lowepower.com> > wrote: > >> Hi John, >> >> I suggest using full system mode instead of SE mode if you're running a >> multithreaded workload. In FS mode, there's a full OS so it can handle >> thread switching, etc. For Parsec on x86 we've created a set of resources >> for you to get started. See >> https://gem5.googlesource.com/public/gem5-resources/+/refs/heads/stable/src/parsec/ >> for details. >> >> Cheers, >> Jason >> >> On Fri, Apr 16, 2021 at 8:07 AM John Smith via gem5-users < >> gem5-users@gem5.org> wrote: >> >>> Hi All, >>> >>> I am sorry for the confusion. >>> >>> I am looking to run a multithreaded application on a mesh of 3x3 CPUs, >>> where the benchmark spawns 9 threads and each thread runs on >>> a single CPU (1:1). I went through the past discussions on this mailing >>> list and saw that m5threads was needed to do this. I have some questions. >>> >>> (1) If there are 9 CPU, and the host CPU launches 9 threads, then are 8 >>> threads launched on the remaining 8 CPUs and the 9th thread has to wait for >>> a >>> thread to complete to begin execution. If not then where does it run as >>> all the 9 CPUs are currently running a thread (1 host + 8 threads). >>> >>> (2) Anthony Gutierrez said that m5threads is no longer needed. Is that >>> correct for gem5-21 ? >>> (Subject: Simulating multiprogrammed & multithreaded workloads in >>> SE mode?) >>> >>> (3) Right now I am trying to build PARSEC 3.0 benchmarks with m5threads, >>> but I am receiving some errors as follows and I am not sure why: >>> >>> >>> >>> >>> >>> *base_dir/local/gcc/bin/gcc -O3 -g -funroll-loops -fprefetch-loop-arrays >>> base_dir/gem5dev/parsec-3.0/pkgs/pthread.o -static-libgcc >>> -Wl,--hash-style=both -Wl,--as-needed -DPARSEC_VERSION=3.0-beta-20150206 -o >>> siman_tsp siman_tsp.o -L base_dir/local/gcc/lib64 -L >>> base_dir/local/gcc/lib ./.libs/libgslsiman.a ../rng/.libs/libgslrng.a >>> ../ieee-utils/.libs/libgslieeeutils.a ../err/.libs/libgslerr.a >>> ../sys/.libs/libgslsys.a ../utils/.libs/libutils.a -lpthread >>> -lmbase_dir/gem5dev/parsec-3.0/pkgs/pthread.o: In function >>> `__pthread_initialize_minimal':pthread.c:(.text+0x97): undefined reference >>> to `_dl_phdr'pthread.c:(.text+0xd9): undefined reference to `_dl_phnum'* >>> >>> Generally how should I go about integrating the m5thread with any >>> benchmark? >>> >>> (4) Also, what other CPU benchmarks are recommended which are >>> multithreaded and can be run in a manner where I can >>> launch a thread on each CPU ? >>> >>> Thank You, >>> John Smith >>> >>> <https://www.mail-archive.com/search?l=gem5-users@gem5.org&q=from:%22Gutierrez%2C+Anthony%22> >>> >>> On Fri, Apr 16, 2021 at 1:50 AM Gabe Black via gem5-users < >>> gem5-users@gem5.org> wrote: >>> >>>> That's essentially right, although gem5 does have some plumbing to run >>>> multiple event queues within the same simulation which can coordinate with >>>> each other within a small window (quantum) of time. gem5 has support for >>>> fibers/threads/coroutines, but these are not typically used to model >>>> events. Events are processed inline when they happen using a simple >>>> function call. >>>> >>>> Gabe >>>> >>>> On Thu, Apr 15, 2021 at 2:46 AM gabriel.busnot--- via gem5-users < >>>> gem5-users@gem5.org> wrote: >>>> >>>>> Hi John, >>>>> >>>>> Short answer : no, you can only run several simulations in parallel, >>>>> but not a single simulation using one thread per CPU. >>>>> >>>>> Gem5 relies on Discrete Event Simulation (DES) to simulate the >>>>> concurrent behavior of HW. >>>>> DES is intrinsically sequential in its execution as it relies on >>>>> coroutines (also called user user threads, greed threads, fibers, etc.). >>>>> Parallelizing such application is a very hard task that often requires >>>>> a lot of subtle code transformations to efficiently protect shared >>>>> resources. >>>>> If done correctly, then parallel DES does not have all the good >>>>> properties of classic DES, especially determinism... Unless you add extra >>>>> care to preserve it, which is hard, too. Trust me ;). >>>>> >>>>> This question has been discussed back in the days but seems stalled >>>>> now: http://www.m5sim.org/Parallel_M5 >>>>> >>>>> Cheers, >>>>> 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 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
