Actually, I see only a very marginal performance difference between your mapeBase_v4 (the first v4, don't know about the second v4) and the loop version, roughly 10%. Not sure why you're seeing a big difference.
As for the "crystal clear" thing: my background is almost 20 years of heavy Matlab use. Cryptic one-liners and contorted vectorizations are second nature to me. Quite often, reduce and generators make things easier and clearer, but not this time, even for me. On Wednesday, October 26, 2016 at 4:55:45 PM UTC+2, Gregory Salvan wrote: > > 2016-10-26 13:09 GMT+02:00 DNF <oyv...@gmail.com <javascript:>>: > >> I don't have the impression that reduce is slow. The reduce function that >> you're using is complicated and may have features that preclude >> optimizations, such as vectorization. >> > > I don't know exactly why, the difference is bigger than what I was > expected. for example with A and F = rand(100_000_000) I have: > > mapeBase_v1 > BenchmarkTools.Trial: > samples: 26 > evals/sample: 1 > time tolerance: 5.00% > memory tolerance: 1.00% > memory estimate: 32.00 bytes > allocs estimate: 1 > minimum time: 194.51 ms (0.00% GC) > median time: 197.77 ms (0.00% GC) > mean time: 198.77 ms (0.00% GC) > maximum time: 220.32 ms (0.00% GC) > mapeBase_v4 > BenchmarkTools.Trial: > samples: 1 > evals/sample: 1 > time tolerance: 5.00% > memory tolerance: 1.00% > memory estimate: 37.25 gb > allocs estimate: 1799998401 > minimum time: 58.77 s (3.04% GC) > median time: 58.77 s (3.04% GC) > mean time: 58.77 s (3.04% GC) > maximum time: 58.77 s (3.04% GC) > > > If you have tips to help me understand this huge difference and eventually > optimize (I've tried to look at llvm ir but it's quite hard for my level, > I've just noted a lot of "store" but don't understand why it's done this > way) > > > >> >> But perhaps more importantly, the reduce version, while probably very >> clever, is almost completely impossible to understand. I know what it's >> supposed to do, and I still cannot decipher it, while the straight loop is >> crystal clear and easy to understand. And almost as concise! >> > > "crystal clear"... depends on your background and habits. > V4 is more natural for me than V1, probably because when I need a single > result (sum, abs...) from a list of values my first option is always > reduce, and I assimilate for loop with kind of "repeat something for each > of these values" > Then I also avoid nested blocks and use a lot guard clauses at the point I > read them as a part of function signature (by default I would naturally > extract v1 for loop content to a function with a guard clause), so my eyes > only catch the operation used to reduce the list in the form of the > expected result. > > This is not adapted to julia and I have to change these habits which is > not a problem as julia is such a pleasure to use. > > >
