Discussion:
Intel KNL test machine
(too old to reply)
Lukas Odzioba
2016-09-08 11:00:14 UTC
Permalink
Raw Message
But KNL is a host CPU; it supports normal DDR and in
the meantime also has its own high-bandwidth memory, which is called
MCDRAM [1]. DDR is the default; special functions are needed to
utilize MCDRAM.
There will be also a card version later.
MCDRAM is visible to OS as a separate NUMA node, so you can use it via
$ numactl -m 1 ./john ... if KNL is in flat mode. If you can and want
to modify the source code the simplest way is to use mmap/mbind
syscalls to allocate memory. In BIOS you can set MCDRAM to cache mode
where it will be direct mapped 16GB cache of your DDR.

Thanks,
Lukas
Lei Zhang
2016-09-08 03:34:04 UTC
Permalink
Raw Message
Hi Lei,
It's been a while since I last posted to john-dev :D
Welcome back!
I've just got access to a new KNL machine; I'm not sure what exact
model it is, but it has 64x4 cores and /proc/cpuinfo says "Intel(R)
I guess some of you might be interested how JtR performs on this
beast. Just let me know if there's any kind of benchmark you want me
to test. And please keep the benchmarking easy to follow, or I may not
have enough time for it :)
Yes, thanks. Lukas already ran some benchmarks on a similar device, but
I think he never published those, in part because the descrypt ones were
for AVX2 rather than AVX-512. We need to fix the code so that we would
use AVX-512 for descrypt - this might be as simple as treating __AVX512F__
same as __MIC__ in more places - perhaps in DES_bs_b.c and in some .h
files. Maybe you can fix this for and prior to running your benchmarks?
As to what benchmarks, let's start with a simple "--test" of the CPU
formats (treating this device as a CPU).
Ok, here's the first run. I only changed DES_bs_b.c to add test for
__AVX512F__. It took about 40 minutes to finish. A few formats failed
and some seem to be using AVX2 instead of AVX512. I'll see if can fix
them (or some of them) when I have time. Please see the attachment for
details.

BTW, it seems John doesn't support out of source build. The generated
Makefile always assumes Makefile.dep is under the same directory. It
would be nice if I can use a separate build directory and not mess
object files with source code :)


Lei
Solar Designer
2016-09-09 01:22:47 UTC
Permalink
Raw Message
Post by Lei Zhang
Ok, here's the first run. I only changed DES_bs_b.c to add test for
__AVX512F__. It took about 40 minutes to finish. A few formats failed
and some seem to be using AVX2 instead of AVX512. I'll see if can fix
them (or some of them) when I have time. Please see the attachment for
details.
Thanks. This still says AVX2 for DES - you need to also have the .h
file request and report 512 bits.
Post by Lei Zhang
BTW, it seems John doesn't support out of source build. The generated
Makefile always assumes Makefile.dep is under the same directory. It
would be nice if I can use a separate build directory and not mess
object files with source code :)
Yes, we don't support that currently. If Makefile.dep is the only
issue (which I doubt), working around it may be as easy as "touch
Makefile.dep" (it's usually empty anyway).

Alexander
Solar Designer
2016-09-09 01:25:19 UTC
Permalink
Raw Message
The memory model also changed. In KNC native mode, all memory usage
happens in the co-processor's 8GB high-bandwidth memory (I forgot the
exact name...). But KNL is a host CPU; it supports normal DDR and in
the meantime also has its own high-bandwidth memory, which is called
MCDRAM [1]. DDR is the default; special functions are needed to
utilize MCDRAM.
I don't know how much impact memory throughput has on John's
performance. Perhaps John needs to explicitly support KNL's memory
model to fully extract performance from it.
For most hash types, there should be almost no difference. For scrypt,
Argon2 and such, there should be significant difference.

Alexander

Loading...