[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <103C046C-1F53-4BC0-A0E0-480023EE124F@apple.com>
Date: Mon, 9 Aug 2010 02:48:05 -0700
From: Eric Christopher <echristo@...le.com>
To: john-users@...ts.openwall.com
Subject: Re: macosx-x86-64 and macosx-x86-sse2 targets
Hi Alexander,
> Thank you for figuring this out, coming up with a workaround, testing,
> and sharing it with the John user community! I appreciate this.
My pleasure.
> I am uncomfortable about including this workaround in the default
> Makefile. I find it likely that gcc's instruction scheduling benefits
> some of the hash types (especially those supported with the jumbo patch,
> the source code for many of which is largely unoptimized).
> Additionally, some CPUs may benefit from gcc rescheduling the
> operations compared to their ordering in the C source (when gcc is
> optimizing for a particular and proper CPU family).
>
Definitely true, we've done some testing with the gcc we ship on the system
to make sure turning off scheduling didn't regress on any of the machines
we have handy, but that's not perfect assurance I understand.
> The "hand scheduling" in the C source was never meant to propagate to
> the compiled code as-is. It was just a way of thinking while editing
> the source code - to see whether sufficient parallelism was available or
> not (and make adjustments to make more parallelism available if needed
> and possible). I always expected the compiler to reschedule as needed
> for the target CPU family.
>
Well, you did a great job :)
> Ideally, the issue should be fixed in llvm-gcc.
Working on it :)
> Meanwhile, it'd be great to be able to specify compiler options at the beginning of a
> source file, inside an #if on particular compiler version(s). Trying
> to do the same in a Makefile or at an even higher level introduces
> "unneeded" complexity, so I am uncomfortable about doing that. But I
> could use this inside-source-file compiler options feature (non-existent
> in gcc and llvm-gcc?) I wished this were possible on many occasions.
>
In the Apple gcc there has been, but I wouldn't really suggest it - and I don't
think it'll work for scheduling options anyhow.
At any rate I'm working on getting us to schedule the code better in general - a hybrid
between latency, ilp and register pressure. That said I did want to give people a
heads up on what to do if you've seen a slowdown on OS X when switching
compilers.
-eric
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.
