Open vsbuffalo opened 4 months ago
So interestingly this isn't an issue on Apple silicon:
command bedtools time granges time granges speedup (%)
------------ --------------- -------------- ---------------------
map_multiple 133.10 s 67.61 s 49.2089
adjust 63.30 s 33.18 s 47.5765
map_min 414.12 s 291.08 s 29.7102
map_mean 410.42 s 276.49 s 32.6327
map_max 417.44 s 281.10 s 32.6611
map_sum 425.98 s 276.15 s 35.1739
map_median 419.66 s 294.14 s 29.9112
flank 86.00 s 51.95 s 39.5932
filter 78.36 s 43.85 s 44.0442
windows 287.13 s 49.90 s 82.6225
vs Ubuntu x86_64
command bedtools time granges time granges speedup (%)
---------- --------------- -------------- ---------------------
map_max 530.72 s 571.12 s -7.61291
map_min 537.00 s 611.83 s -13.9352
map_mean 534.22 s 572.59 s -7.18139
map_sum 561.18 s 601.37 s -7.16121
map_median 570.75 s 549.84 s 3.6649
So interestingly this isn't an issue on Apple silicon:
command bedtools time granges time granges speedup (%) ------------ --------------- -------------- --------------------- map_multiple 133.10 s 67.61 s 49.2089 adjust 63.30 s 33.18 s 47.5765 map_min 414.12 s 291.08 s 29.7102 map_mean 410.42 s 276.49 s 32.6327 map_max 417.44 s 281.10 s 32.6611 map_sum 425.98 s 276.15 s 35.1739 map_median 419.66 s 294.14 s 29.9112 flank 86.00 s 51.95 s 39.5932 filter 78.36 s 43.85 s 44.0442 windows 287.13 s 49.90 s 82.6225
vs Ubuntu x86_64
command bedtools time granges time granges speedup (%) ---------- --------------- -------------- --------------------- map_max 530.72 s 571.12 s -7.61291 map_min 537.00 s 611.83 s -13.9352 map_mean 534.22 s 572.59 s -7.18139 map_sum 561.18 s 601.37 s -7.16121 map_median 570.75 s 549.84 s 3.6649
Is this "apples to apples" ? (Pun intended.) The raw times reported for Apple Silicon are 10X less than for Ubuntu/x86. Are you sure that the Apple numbers reflect "large data" tests?
On a second read, maybe the Apple Silicon numbers are okay? They're not 10x smaller but more like 2x?
On large (1M ranges) datasets, bedtools map is beating GRanges. It look like it comes down to numerics:
where inline here refers to
#[inline(always)]
above theOperations::run()
(suggested by @molpopgen).