Displaying 4 results from an estimated 4 matches for "nuber_of_thread".
Did you mean:
nuber_of_threads
2014 Apr 17
2
[LLVMdev] multithreaded performance disaster with -fprofile-instr-generate (contention on profile counters)
...extra shards.
> }
Is it possible to hook on something more clever than function entry?
Choosing to do this based on thread creation or something like that
could make this extra check very cheap.
> MAX is a fixed cap so even on systems with 100s of cores we don't do something
> silly. NUBER_OF_THREADS, if supported on the OS, can limit the shards when we
> only have a small number of threads in the program. NUMBER_OF_CORES, if
> supported on the OS, can limit the shards. If we don't have the number of
> threads, we just use the number of cores. If we don't have the number of
&g...
2014 Apr 17
9
[LLVMdev] multithreaded performance disaster with -fprofile-instr-generate (contention on profile counters)
Hi,
The current design of -fprofile-instr-generate has the same fundamental
flaw
as the old gcc's gcov instrumentation: it has contention on counters.
A trivial synthetic test case was described here:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066116.html
For the problem to appear we need to have a hot function that is
simultaneously executed
by multiple threads -- then we will
2014 Apr 17
2
[LLVMdev] multithreaded performance disaster with -fprofile-instr-generate (contention on profile counters)
...MBER_OF_THREADS,
> NUMBER_OF_CORES));
> // if shard_count changed with this, we can also call a library routine
> here that does the work of allocating the actual extra shards.
> }
>
> MAX is a fixed cap so even on systems with 100s of cores we don't do
> something silly. NUBER_OF_THREADS, if supported on the OS, can limit the
> shards when we only have a small number of threads in the program.
> NUMBER_OF_CORES, if supported on the OS, can limit the shards. If we don't
> have the number of threads, we just use the number of cores. If we don't
> have the number...
2014 Apr 18
4
[LLVMdev] multithreaded performance disaster with -fprofile-instr-generate (contention on profile counters)
...eck very cheap.
>
> Yea, *if* you can do it on thread creation, that would be awesome. But we don't really have a good way to model that right now. on the flip side.
>
>
> > MAX is a fixed cap so even on systems with 100s of cores we don't do something
> > silly. NUBER_OF_THREADS, if supported on the OS, can limit the shards when we
> > only have a small number of threads in the program. NUMBER_OF_CORES, if
> > supported on the OS, can limit the shards. If we don't have the number of
> > threads, we just use the number of cores. If we don't have t...