[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
