# \`\`\`@turbo\`\`\` producing different (and wrong) results compared to \`\`\`@inbounds @simd\`\`\`
**URL:** https://discourse.julialang.org/t/turbo-producing-different-and-wrong-results-compared-to-inbounds-simd/96851
**Category:** General Usage
**Tags:** bug, simd, potential-bug, loopvectorization
**Created:** [March 30, 2023, 5:16pm UTC](https://discourse.julialang.org/t/turbo-producing-different-and-wrong-results-compared-to-inbounds-simd/96851 "2023-03-30T17:16:25Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@bremez](https://discourse.julialang.org/u/bremez)
#### Post date: [March 30, 2023, 5:16pm UTC](https://discourse.julialang.org/t/turbo-producing-different-and-wrong-results-compared-to-inbounds-simd/96851/1 "2023-03-30T17:16:25Z")
I have a use case where an integer array contains only values between 1 and some `maxValue`, and I would like the histogram of the array values. I found that `counts(array, maxValue)` was too slow, and as best as I could understand, it scans the array `maxValue` times to count each possible value separately, instead of scanning the array once.
I thought then to implement this by hand with
```julia
using LoopVectorization
function mycounts(array, maxValue)
count = zeros(Int64, maxValue)
@turbo for i in eachindex(array)
count[array[i]] += 1;
end
return count;
end
```
However, I found that this produces the wrong results. For example `mycounts(ones(Int64, 1024)` gives `32` instead of `1024`, and in fact increasing the size of the array, I always get 1-32th of the correct value. So perhaps this might have to do with the loop unrolling factor of `@turbo`? I can confirm that replacing it with `@inbounds @simd`, I get the correct results. Is there some nuance to the safe operation of `@turbo` relative to `@simd` that I am missing, or is this an actual bug that I should report?
(Since I have `maxValue` of order 100, the speed savings with `@simd` are already significant; yet the (wrong) implementation with `@turbo` gains another x5 performance boost compared to `@simd` which would be nice to have.)
---
### Author:  [@Elrod](https://discourse.julialang.org/u/Elrod)
#### Post date: [March 30, 2023, 5:23pm UTC](https://discourse.julialang.org/t/turbo-producing-different-and-wrong-results-compared-to-inbounds-simd/96851/2 "2023-03-30T17:23:50Z")
This is a known issue. The issue is that `@turbo` assumes the indices `array[i]` do not alias one another.
Reading and writing to the same index of `count` at the same time (because that assumption is wrong) is why the answer is wrong.
---
### Author:  [@bremez](https://discourse.julialang.org/u/bremez)
#### Post date: [March 30, 2023, 5:28pm UTC](https://discourse.julialang.org/t/turbo-producing-different-and-wrong-results-compared-to-inbounds-simd/96851/3 "2023-03-30T17:28:23Z")
@Elrod Just to be sure, I’ve had instances where I `@turbo` a loop that, say, adds to the same scalar accumulator, and I didn’t see an issue. So this has to do with the indexing into `count`? Is there a way to tell when I should and should not use `@turbo`?
---
### Author:  [@Elrod](https://discourse.julialang.org/u/Elrod)
#### Post date: [March 30, 2023, 5:34pm UTC](https://discourse.julialang.org/t/turbo-producing-different-and-wrong-results-compared-to-inbounds-simd/96851/4 "2023-03-30T17:34:30Z")
> [@bremez](#):
>
> @Elrod Just to be sure, I’ve had instances where I `@turbo` a loop that, say, adds to the same scalar accumulator, and I didn’t see an issue.
Yeah, if you do
```julia
count +=
```
it knows it is the same count, and (if it has to) will create a bunch of copies of `count` so that it can add them in parallel, and combine them at the end.
With
```julia
count[i] +=
```
it currently just assumes that every `i` is unique so that it doesn’t have to do that.
If it didn’t assume that, it could in principle do the same thing as it does for `count`, and create a bunch of parallel accumulators, one for `eachindex(count)`. However, that could be arbitrarily expensive…
[vpconflict](https://uops.info/html-instr/VPCONFLICTQ_ZMM_ZMM.html) may be a better option on CPUs with AVX512, but it isn’t too fast, so that a scalar loop may be the way to go.