|
Message-ID: <20150817195042.GA2876@openwall.com> Date: Mon, 17 Aug 2015 22:50:42 +0300 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: Sybase-PROP (Re: FMT_OMP_BAD) On Mon, Aug 17, 2015 at 02:32:08PM -0500, JimF wrote: > I find it to be overall faster but I was not having much OMP scale issue > before: Oh. Due to what the problem was, I am not surprised that it affected different systems differently. In fact, I am a bit surprised that it did result in that poor OpenMP scaling on super. I would have expected uses of Rot2() to become fast on all threads eventually (after some cache line bouncing between the CPUs), but somehow this wasn't happening on super. The code was unsafe (it needed memory barriers), so it could have misbehaved, but I am surprised the cache coherence mechanisms apparently never entered a stable state even when running for a second. I also wonder if adding the proper memory barriers would have avoided the slowdown. This would be curious to test, and it has implications on lots of other (correct) code. > Before > $ ../run/john -test=5 -form=sybase-prop > Will run 8 OpenMP threads > Benchmarking: Sybase-PROP [salted FEAL-8 32/64]... (8xOMP) DONE > Many salts: 2586K c/s real, 349628 c/s virtual > Only one salt: 2552K c/s real, 339893 c/s virtual > > After > $ ../run/john -test=5 -form=sybase-prop > Will run 8 OpenMP threads > Benchmarking: Sybase-PROP [salted FEAL-8 32/64]... (8xOMP) DONE > Many salts: 3380K c/s real, 452501 c/s virtual > Only one salt: 3269K c/s real, 451823 c/s virtual > > This is on a 4 core HT system. was getting 7.5x now 7.25x (1 salt). In other words, you're getting slightly worse OpenMP scaling now than before? But overall better speeds, due to improved single-thread speed? Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.