|
From: Alex <spl...@gm...> - 2015-04-10 08:44:50
|
Can someone provide a quick explanation what are the characteristics of VG simulated CPU (cache, cores, core speed, threads)? I need benchmark client code for different hardware with my VG tool plugin. Alex. |
|
From: Julian S. <js...@ac...> - 2015-04-10 11:15:42
|
On 10/04/15 10:44, Alex wrote: > Can someone provide a quick explanation what are the characteristics > of VG simulated CPU (cache, cores, core speed, threads)? I need > benchmark client code for different hardware with my VG tool plugin. V just provides an instruction set simulator, that is, something that can compute the architecturally-visible effects of executing each instruction. There is no attempt made to simulate any microarchitural details (caches etc) -- at least in the core. The Callgrind and Cachegrind tools do simulate that kind of thing. But that's not "core" functionality. J |
|
From: Josef W. <Jos...@gm...> - 2015-04-10 13:02:40
|
Am 10.04.2015 um 10:44 schrieb Alex: > Can someone provide a quick explanation what are the characteristics > of VG simulated CPU (cache, cores, core speed, threads)? Cachegrind/Callgrind simulate one 2-level cache hierarchy with separate L1 data and L1 instuction caches, and unified L2. L1 and L2 are inclusive (not strict inclusive) with write-allocate and LRU replacement. Cache parameters (associativity/sizes) are taken per default from the CPU you run VG on. For newer Intel CPUs with L3, the real L3 parameters are used for the L2 in the cache model. As events, you get number of instructions executed (= fetched from L1), data read and written from/to L1, L1D/L1I and L2 misses. Valgrind serializes threads with a timeslice of 100000 superblocks (which may be around a million guest instructions), and all threads make use of the same cache hierarchy. So it would compare to a single-core with corresponding timeslicing. Any time estimation has to be derived from the collected event counters, and you can use your own assumed core speed here. It allows a 1 clock/instruction core performance plus some penalties for L1/L2 misses. The counters do not provide information about whether an evicted cache line was dirty or clean; thus, the cache model not even makes a distinction between write-through/write-back L1 or L2, as it does not matter. However, in Callgrind, optionally you can switch on tracking of dirty/clean in L2 (--simulate-wb=yes), resulting on more event types. Further, "-simulate-hwpref=yes" enables simulation of a page-based L2 stream hardware prefetcher (which makes every prefetched line into an L2 hit). > I need > benchmark client code for different hardware with my VG tool plugin. What does your tool provide? Josef > > Alex. > |
|
From: Josef W. <Jos...@gm...> - 2015-04-10 15:13:52
|
Can we keep this discussion on the mailing list, so others can add to it? Am 10.04.2015 um 16:35 schrieb Alex: > This tool evaluates the spatial locality for client application (the > length of contiguous data access). I need to test spatial behavior of > various client apps and debug it on single server or cluster to > prevent performance degradation. So it will be better for my analysis > if VG simulated CPU will be closer to my real CPU. I don't understand. Are you worried about doing a wrong analysis when comparing executions within VG vs. native environment? What has this to do with CPU features? As Julian said, VG tries to keep the functional behavior the same, but does not worry about non-functional behavior as you would expect from a simulation (simulated time, simulated energy consumption and so on). Josef This is the only > thing that confuses me. In other respects V is perfect for my > purposes. > > 2015-04-10 16:02 GMT+03:00 Josef Weidendorfer <Jos...@gm...>: >> Am 10.04.2015 um 10:44 schrieb Alex: >>> Can someone provide a quick explanation what are the characteristics >>> of VG simulated CPU (cache, cores, core speed, threads)? >> >> Cachegrind/Callgrind simulate one 2-level cache hierarchy with separate >> L1 data and L1 instuction caches, and unified L2. L1 and L2 are inclusive >> (not strict inclusive) with write-allocate and LRU replacement. >> Cache parameters (associativity/sizes) are taken per default from the CPU >> you run VG on. For newer Intel CPUs with L3, the real L3 parameters are >> used for the L2 in the cache model. >> >> As events, you get number of instructions executed (= fetched from L1), >> data read and written from/to L1, L1D/L1I and L2 misses. >> >> Valgrind serializes threads with a timeslice of 100000 superblocks (which >> may be around a million guest instructions), and all threads make use of the >> same cache hierarchy. So it would compare to a single-core with >> corresponding >> timeslicing. >> >> Any time estimation has to be derived from the collected event counters, >> and you can use your own assumed core speed here. It allows a >> 1 clock/instruction core performance plus some penalties for L1/L2 misses. >> >> The counters do not provide information about whether an evicted cache >> line was dirty or clean; thus, the cache model not even makes a distinction >> between write-through/write-back L1 or L2, as it does not matter. >> >> However, in Callgrind, optionally you can switch on tracking of >> dirty/clean in L2 (--simulate-wb=yes), resulting on more event types. >> Further, "-simulate-hwpref=yes" enables simulation of a page-based >> L2 stream hardware prefetcher (which makes every prefetched line into >> an L2 hit). >> >>> I need >>> benchmark client code for different hardware with my VG tool plugin. >> >> What does your tool provide? >> >> Josef >> >>> >>> Alex. >>> >> >> ------------------------------------------------------------------------------ >> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT >> Develop your own process in accordance with the BPMN 2 standard >> Learn Process modeling best practices with Bonita BPM through live exercises >> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ >> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF >> _______________________________________________ >> Valgrind-developers mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |