[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1ba64b0934581904606610dbf5e11b84@smtp.hushmail.com>
Date: Mon, 19 Aug 2013 19:46:31 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: relbench/benchmark-unify
On 19 Aug, 2013, at 9:44 , Frank Dittrich <frank_dittrich@...mail.com> wrote:
> Checking CUDA and OpenCL formats on bull, I noticed one more problem.
>
> Benchmarking: md5crypt [CUDA]... DONE
> Benchmarking: md5crypt [OpenCL]... DONE
> vs.
> Benchmarking: md5crypt-cuda, crypt(3) $1$ [MD5 CUDA]... DONE
> Benchmarking: md5crypt-opencl, crypt(3) $1$ [MD5 OpenCL]... DONE
>
> May be it doesn't make much sense to compare CPU and GPU formats anyway.
> On the other hand, measuring how much faster a GPU implementation is
> compared to a CPU implementation for a given format might be useful
> information.
> And, without dropping the format labels, I won't be able to easily
> compare CUDA and OPenCL implementations.
>
> This is getting ugly.
> Ideas how to best handle the situation are most welcome.
>
> My best idea so far is to add a new option to benchmark-unify:
> --drop-format-labels[=0|=1]
>
> Default would be to just drop the format labels which are known to be
> alternative implementations:
> *-ng, *-naive, nt2:
>
> --drop-format-labels=0 would be to keep format labels even for those
> alternative implementations.
> --drop-format-labels or --drop-format-labels=1 would mean to drop all
> format labels, even if this makes "RAdmin, v2.x" a useless format name
>
> May be we need to fix those few format names which get meaningless
> without the format label.
>
> Any thoughts?
I'm not sure. Perhaps another solution is another revision of the names and labels, after coming up with some convention(s).
magnum
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.
