range should return something that implements IReduce

Description

range should implement IReduce for fast reduction.

Patch: clj-1515-14.patch - Java range with long optimizations

Approach: The clj-1515-14 patch revives the unused clojure.lang.Range class. This class is similar in implementation to ChunkedCons. It differs by lazily constructing the first chunk (this is done in the existing impl by using a LazySeq wrapper) and by caching the next reference like other seq impls. The latter is done because range is frequently used in both chunked and unchunked traversal.

Additionally, 1515-14 contains an optimized version of range (LongRange) for the extremely common case where start, end, and step are all longs. This version uses primitive longs and primitive math and a customized version of ArrayChunk for greater performance.

The special case of (range) is just handled with (iterate inc' 0) (which was further optimized for reduce in CLJ-1603).

Alternatives:

  • CLJ-1515-deftype3.patch took the approach of using deftype to create a seqable, reducible entity that was not actually a seq. Based on work for CLJ-1603, it was established that due to historical requirements, this is not viable and the entity returned for range should implement the ISeq and Collection interfaces directly.

  • clj-1515-11.patch uses the approach of a "split" implementation - a LazySeq that has a fast reduce path. This is a minimal patch that provides no perf difference for sequence usage but a moderate improvement for reduce paths. One important difference vs clj-1515-12 is that the fast reduce path is only obtained on the initial range. Once you walk off the head, the performance will be the same as prior (seq perf).

Performance

criterium quick-bench with java 1.8.0-b132

code

1.7.0-master

Java clj-1515-14

split clj-1515-11

(count (range (* 1024 1024)))

63 ms

0 ms

58 ms

(reduce + (map inc (range (* 1024 1024))))

50 ms

33 ms

50 ms

(reduce + (map inc (map inc (range (* 1024 1024)))))

68 ms

52 ms

67 ms

(count (keep odd? (range (* 1024 1024))))

73 ms

52 ms

67 ms

(transduce (comp (map inc) (map inc)) + (range (* 1024 1024)))

46 ms

26 ms

34 ms

(reduce + 0 (range (* 2048 1024)))

67 ms

19 ms

40 ms

(reduce + 0 (rest (range (* 2048 1024))))

67 ms

19 ms

57 ms

(doall (range 0 31))

1.04 µs

0.75 µs

1.15 µs

(doall (range 0 32))

1.08 µs

0.76 µs

1.18 µs

(doall (range 0 4096))

135 µs

96 µs

145 µs

(into [] (map inc (range 31)))

1.81 µs

1.30 µs

1.88 µs

(into [] (map inc) (range 31))

1.71 µs

0.75 µs

1.02 µs

(into [] (range 128))

4.82 µs

2.20 µs

3.27 µs

(doall (range 1/2 1000 1/3))

1.24 ms

1.24 ms

1.28 µs

(doall (range 0.5 1000 0.33))

126 µs

147 µs

151 µs

(into [] (range 1/2 1000 1/3))

1.26 ms

1.20 ms

1.26 ms

(into [] (range 0.5 1000 0.33))

148 µs

91 µs

130 µs

(count (filter odd? (take (* 1024 1024) (range))))

185 ms

167 ms

176 ms

(transduce (take (* 1024 1024)) + (range))

67 ms

35 ms

68 ms

Performance notes:

  • 1515-14 (Java) - significant improvements in virtually all use cases, both seq and reduce. The final two cases with (range) leverage optimizations from CLJ-1603.

  • 1515-11 (split) - a much smaller patch that gives no seq benefits and smaller reduction benefits. Only the head of the range will receive the perf benefits (see (reduce + 0 (rest (range (* 2048 1024))))).

Questions
(range) and supports auto-promotion towards infinity in this patch, which seems to be implied by the doc string but was not actually implemented or tested correctly afaict.

Environment

None

Activity

Show:
Fogus
April 10, 2015, 6:14 PM

The latest patch (-14) handles the extraneous allocations from -12. All tests run and timings verified.

Alex Miller
April 3, 2015, 4:29 PM

The -14 patch just switches to leverage Repeat now that 1603 has been applied.

Alex Miller
March 27, 2015, 9:44 PM

New patch -13 removes the array allocation and performs better, still need to update timings and consider the non-long case.

Fogus
March 27, 2015, 7:57 PM

Screened. Though the amount of duplicated code saddens me, I don't hold it against the implementer. It's a fairly straight-forward counting Impl with a chunk cache.

Alex Miller
February 24, 2015, 5:30 PM

current direction is pending results of where CLJ-1603 goes

Completed

Assignee

Unassigned

Reporter

Timothy Baldridge

Labels

None

Approval

Ok

Patch

Code and Test

Fix versions

Affects versions

Priority

Major