[concurrency-interest] Ops type names
dl at cs.oswego.edu
Mon Jan 7 20:25:39 EST 2008
Rémi Forax wrote:
> Why not using internal classes for all specialized types like
> java.awt.geom do.
> something like:
> Reducer.Double, Reducer.Long, etc.
> and Comparator.Double, Comparator.Int, etc.
The names that people seem to like the least are the
ones that cross types, which this doesn't seem to help.
That is, while DoubleMapper sounds/reads fine,
the variants that take or return other types all look and sound
(These are the ones for which Neal's function type language proposal
works much better for -- see
A possible small improvement is to use a variant of David Biesack's
scheme only for these mixed types:
These seem only a little better if at all.
But maybe some of you have better ideas along these lines?
Notice also that Ops does not even try to define the various
scalar specializations of Combiners. Which here might look like,
(Luckily none of the ParallelArray classes use such types.)
Aside: all of these naming schemes have the flaw that they look
like they apply to boxed types ("Double") not scalars ("double"),
but don't; and in fact autoboxing usually won't work on them...
Further aside: Note that these naming and usage issues crop up
because of the need to support scalar long and double versions.
(Without them, just "Mapper", "Predicate", etc suffice.)
So people using them are doing so for the sake of performance.
As I've mentioned before though, the performance differences
of, for example, boxed Longs vs scalar longs are magnified
by parallelism, so it is not uncommon to see scalar versions
of parallel map, reduce, sort, etc run, say, four times faster
than boxed versions. So I'd like to minimize the hurdles people
have to go through to use the more efficient versions.
(Maybe eventually boxing will be comparable to scalar, but there
are some huge obstacles to overcome, so it won't be soon.)
More information about the Concurrency-interest