в общем видимо быстрее всего либо самому в цикле проверить, индексируясь по срезу (slice), либо вынести этот цикл в функцию с макросом @inline

Ну если какого-то умного reduce не завезли...

По идее они все создают массив булевых значений, ибо невозможно догадаться, что ты с этим чудом делать будешь

all(y->y==x[1], x) - вот это точно нельзя адаптировать? Я до компа через час доберусь, сам если что проверю, но, кажется, можно

Kirill А ты на какой версии тестишь?

я на Julia 0.6

я на работе никак не мигрирую на 1.0, у нас с установкой нового ПО всё очень сложно )

function ar_equal1(v, y, startInd, endInd)
   return v[startInd:endInd] == y[startInd:endInd]
end

function ar_equal1v(v, y, startInd, endInd)
   return view(v, startInd:endInd) == view(y, startInd:endInd)
end


function ar_equal2(v, y, startInd, endInd)
   return all(i->v[i] == y[i], startInd:endInd)
end


function ar_equal3(v, y, startInd, endInd)
   return all(i->v[i] == y[i], startInd:endInd)
end  

@inline function ar_equal4(x, y, startInd, endInd)
   for i=startInd:endInd
       x[i] == y[i] || return false
   end
   return true
end

y =  collect(1:10_000_000)
v = collect(1:10_000_000)

@btime ar_equal1(y, v, 2, 9999999)
@btime ar_equal1v(y, v, 2, 9999999)
@btime ar_equal2(y, v, 2, 9999999)
@btime ar_equal3(y, v, 2, 9999999)
@btime ar_equal4(y, v, 2, 9999999)

Далее btime показывает проблему только для первого подхода. У остальных скорость схожая. У второго даже лучше) Но наверно можно inbounds сделать схожей (я делал  - прироста скорости не ощутил, в общем случае небезопасно, надо проверять входные массивы, потому для простоты забил).

это верно только для всяких all(), для обычного сравнения должно быть понятно, видимо они и поняли.

Вот тут некоторый набор текстов по приторможенному в 2015 году проекту создания языка системного моделирования SysMoLan — https://ailev.livejournal.com/1443879.html

Сейчас обсуждается идея о том, чтобы реализовать этот язык в варианте встроенного в Julia DSL.

на 0.6.4 результаты похуже, и у ar_equal4 едет крыша по аллокациям и скорости, видимо, они каждый маленький float заново аллоцируют, иначе объяснить не могу. ar_equal1v начинает вести себя тоже нехорошо, но не настолько. Остальные только чуть медленнее.

А почему так?
```
y =  [x for x in 1:10_000_000]
v = [x for x in 1:10_000_000]
```

Вроде классично

y = collect(1:10_000_000)
v = collect(1:10_000_000)

да, ссори, я не мог вспомнить название этой функции, у меня она почему-то как consume всплывала, подумал, что из залетного пакета была

Для Julia1.0. Для случая равенства
 51.832 ms (4 allocations: 152.59 MiB)
 9.801 ms (2 allocations: 96 bytes)
 9.747 ms (2 allocations: 64 bytes)
 9.953 ms (2 allocations: 64 bytes)
 9.307 ms (0 allocations: 0 bytes)

Если в середину вставляю неравный элемент:
 44.526 ms (4 allocations: 152.59 MiB)
 4.843 ms (2 allocations: 96 bytes)
 4.535 ms (2 allocations: 64 bytes)
 4.552 ms (2 allocations: 64 bytes)
 4.616 ms (0 allocations: 0 bytes)

Видимо, разница просто в пределах отклонения (на другом запуске второе быстрее было). Случайно не то вставил, отредачил

спасибо, глянем дома! ))

Надо ещё глянуть, что будет, если смотреть много раз по небольшим кусочкам

Наподобие

for i in 1 : 10_000
Сравнить кусочки длины 100 в v и у

Посоветуйте аналоги на русском книге CTM, сорри если оффтоп.

Несколько замечаний:
1. В Benchmarktools надо использовать интерполяцию, иначе результаты получаются некорректными.
То есть вместо @btime ar_equals3(y, v, 2, 999999) надо писать @btime ar_equals3($y, $v, 2, 9999999)
На моей машине (c julia 1.0) разница такая:

v1 = collect(1:10_000)
v2 = collect(1:10_000)

@btime ar_equals3(v1, v2, 2, 9999)
# 16.194 μs (3 allocations: 96 bytes)

@btime ar_equals3(v1, v2, 2, 9999)
# 15.882 μs (0 allocations: 0 bytes)

то есть немного дольше работает и появляются дополнительные аллокации