[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080718141730.GA949@openwall.com>
Date: Fri, 18 Jul 2008 18:17:30 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: JtR 1.7.3.1
Hi Sebastian,
On Fri, Jul 18, 2008 at 02:41:25PM +0200, Sebastian Rother wrote:
> But I'd like to ask if you may could decide to release a new "stable"
> version some time.
Indeed, but unfortunately not soon. So far, "stable" releases of JtR
assumed testing on a lot of platforms and pre-building for Windows and
DOS, which I did not do this time. (I did not even try compiling this
release on Windows, although that should work.) Also, the plan has been
to make major releases of JtR infrequently, and to issue minor updates
to those for critical bugs only (this was the case for 1.7.0.1 and
1.7.0.2, although I also included some reliability enhancements along
with the bugfixes).
> The problem with the ports-maintainer on OpenBSD is,
> that he wont include "unstable" (aka development) versions so far.
What if the web page explicitly says what it does now? -
In practice, 1.7.2 (a "development" version) has been around for a long
time now, and it has been found to be at least as stable as 1.7.0.2, so
the use of 1.7.2 is recommended.
I can't say that of 1.7.3.1 yet, but I hope that eventually I will.
> Could you name some CPUs wich would help you?
Any Itanium. Alpha 21264 (EV6) or newer. Pretty much anything "recent".
Also, testing with very recent gcc (such as 4.3.1) and with other C
compilers on RISC architectures makes sense. You may either use "make
generic", which autodetects BF_X2, or (re)set BF_X2 in the .h file for
your arch manually. Then let me know whether BF_X2=0 or BF_X2=1 works
better (and by how much) for your specific CPU, compiler, version.
> You wrote something about RISC and 2 int instruction per clock.
> Could you name some SPARC CPUs in case you know some?
I've already tested on UltraSPARC IIi with gcc up to 3.4.5, so I am
interested in tests on newer UltraSPARC and SPARC64 CPUs and/or with
newer/other compilers.
Yes, I did mention that this optimization is most effective for CPUs
that can issue more than 2 integer instructions per cycle, but in
practice things are more complicated - it's not only about peak
issue rate, but it's also about latencies. So it could make sense on
some dual-issue and even single-issue CPUs as well, if the compiler
generates good code (those versions of gcc failed at that) and if some
of the instructions involved have large latencies.
Thanks,
Alexander
--
To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply
to the automated confirmation request that will be sent to you.
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.
