[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU159-W498F3E44890B1E0FD93111A4710@phx.gbl>
Date: Fri, 3 Feb 2012 21:57:34 +0000
From: Alex Sicamiotis <alekshs@...mail.com>
To: <john-users@...ts.openwall.com>
Subject: RE: DES with OpenMP
> I was literally referring to the output of command:
>
> size DES_bs_b.o
>
> Specifically, the number it reports for the .text section. It should be
> around 30 KB, but will vary slightly between the builds.
>
> File sizes do not matter - they mostly reflect debugging info and the
> like, which does not affect performance.
>
> I'm sorry that I did not state this more clearly.
>
No worries...
http://imageshack.us/f/69/resultsarein3.png/
...thing with ICC is probably the -fast command which does an -ipo in the end. This leads to showing zeros to both openmp and non-openmp files with size DES_bs_b.o
-fast implies -O3 -static -ipo so I did a compile run with just -O3 and -static to check code size but these executables without the -ipo have no relevance to the -ipo version which I'm running so, perhaps, the resulting code size is meaningless since I'm not testing these builds.
Btw the non-openmp with -O3 and static compiled ok. The openmp ver with -O3 and -static didn't compile at all but I could still see the size of the .o file.
make clean linux-x86-64
...
icc -c -Wall -O3 -static -fomit-frame-pointer -fopenmp -msse2 -DHAVE_CRYPT -funroll-loops c3_fmt.c
icc -c -fopenmp -msse2 x86-64.S
icc DES_fmt.o DES_std.o DES_bs.o DES_bs_b.o BSDI_fmt.o MD5_fmt.o MD5_std.o BF_fmt.o BF_std.o AFS_fmt.o LM_fmt.o trip_fmt.o dummy.o batch.o bench.o charset.o common.o compiler.o config.o cracker.o crc32.o external.o formats.o getopt.o idle.o inc.o john.o list.o loader.o logger.o math.o memory.o misc.o options.o params.o path.o recovery.o rpp.o rules.o signals.o single.o status.o tty.o wordlist.o unshadow.o unafs.o unique.o c3_fmt.o x86-64.o -s -fopenmp -msse2 -lcrypt -o ../run/john
DES_bs.o: In function `DES_bs_init':
DES_bs.c:(.text+0x1444): undefined reference to `DES_bs_set_salt_for_thread'
make[1]: *** [../run/john] Error 1
make[1]: Leaving directory `/john/john-1.7.9-icc/src'
make: *** [linux-x86-64] Error 2
I'm not particularly interested in building this (-fast is faster with the -ipo), just reporting it since it "bounced".
Btw #2, I've also run into plenty of trouble with the Open64 (5.0) and AMD Open 64 (4.5.1) which I've been experimenting with (it's generally quite slower than gcc and icc). Too many compilation and runtime issues which is almost certainly due to compiler maturity or inherent limitations. If it was producing faster binaries it might even worth a look into making the code more open64-compatible. 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 (?).
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.
