Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: stdcbench benchmark Date: Fri, 20 Apr 2018 14:22:04 -0700 Organization: None to speak of Lines: 30 Message-ID: References: <8w3BC.5780$yK2.5645@fx16.iad> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="7da0823167140a0eba130b9354997562"; logging-data="24352"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+hdzCF6NBECplzRoZsU3WK" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:M/7L/jgF+YaE7fOkE2C30jHnMUc= sha1:CeO/F0fnHI2JLUOvxhjOI1YxuwY= Xref: csiph.com comp.lang.c:129545 scott@slp53.sl.home (Scott Lurndal) writes: > bartc writes: >>On 16/04/2018 15:41, Scott Lurndal wrote: [...] >>> Indeed. The application I'm currently working on has between 6 >>> and 96 threads running flat-out, 100%. No I/O. Might block >>> infrequently waiting for a mutex, very infrequently, the threads >>> are pretty much independent. Every cycle matters, so >>> work goes into looking at L1/L2 cache behavior, data layout wrt >>> cache-lines, compiler optimzations, and inline micro-optimizations >>> (e.g. avoiding blocking operations like mutexes when possible by using >>> atomics instead) >> >>How much difference would it make if you left all that in place, but >>switched off compiler optimisations? > > It runs 20 to 40 times slower. That's interesting. The application is in C, right? Is there something unusual about your application that results in such extreme speed improvement from optimization? (You mentioned inlining.) Can you share the source? (I suspect the answer is no, but I thought I'd ask.) -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"