|
Message-ID: <BLU159-W25B147708A02DBC384960AA4710@phx.gbl> Date: Fri, 3 Feb 2012 23:03:59 +0000 From: Alex Sicamiotis <alekshs@...mail.com> To: <john-users@...ts.openwall.com> Subject: RE: DES with OpenMP > I don't mind making the source code more compatible with another > compiler even if the resulting binaries are slower right now. This may > help improve code portability in general, and it may assist in more > extensive testing of further changes to John. So you may report > specific compile errors you're getting - perhaps to john-dev since > builds with Open64 are in fact of little relevance to john-users now and > since the postings will be expected to result in discussions of the > relevant places in the source code. > Ok, although I'll wait for a next release of Open64. The last 2 versions I've experimented with were pretty disappointing. If I had a bulldozer I would surely try to squeeze whatever I could get out of it but with an intel wolfdale it doesn't make much sense right now. I tried clang which is far better for my hardware but it lacks openmp functionality and for DES, which I'm particularly interested in, it doesn't make faster code than gcc 4.3 or icc 12.1. > > I am not sure if this applies to bulldozer or xop-specific customisations. There was a benchmark in phoronix that was quite impressive (c-ray): > > > > http://www.phoronix.com/scan.php?page=article&item=amd_bulldozer_compilers&num=2 > > > > 3d rendering (which is pretty intensive in calculations) got very fast on the bulldozer with the Open64, "bulldozing" even the overclocked i5's and 6-core i7's: http://www.phoronix.com/scan.php?page=article&item=intel_corei7_3960x&num=7 ...this MAY imply cracking potential that is simply unavailable in GCC (?). > > Hardly. This is more likely either a special case that would not apply > here or even just an artifact of Phoronix's benchmarking. Could be... time will tell. My experience with rendering 3d stuff is that if the end result is presented faster => the processing throughput is definitely there / it can't be a fluke. Of course if the binary was broken and the rendering stopped halfway with the timer ending prematurely, that could be an artifact of epic proportions, heh. Speaking of > the latter, Phoronix is notorious for not mentioning the details of how > the software was built. Indeed. > Note the level of detail - just what is needed and just what we don't > get from Phoronix. So I was able to add these newer results to the wiki: > Yep, for development purposes accuracy is essential.
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.