Opened 4 years ago
Closed 4 years ago
#1467 closed defect (fixed)
std::sort() may cause cross-platform performance mismatch
Reported by: | hanhuang | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | VTM | Version: | VTM-12.0 |
Keywords: | Cc: | ksuehring, XiangLi, fbossen, jvet@… |
Description
The std::sort() may produce different results in different platforms (linux and windows for examples) if some of the elements have equal comparison values. Therefore, could cause different encoding results using the same VTM.
There are two std::sort function calls that are identified to have potential issue. One in IntraSearch::xSortISPCandList and the other in EncAdaptiveLoopFilter::determineControlIdcValues.
It's suggested to replace std::sort with std::stable_sort to avoid potential cross-platform performance mismatch.
Change history (5)
comment:1 follow-up: ↓ 2 Changed 4 years ago by fbossen
comment:2 in reply to: ↑ 1 ; follow-up: ↓ 3 Changed 4 years ago by hanhuang
Replying to fbossen:
Yes, it would make sense to use stable_sort in these cases for consistency. Presumably the arrays are small enough such that no impact on runtime is expected.
What about GeoComboCostList::sortByCost ?
Yes, the sortByCost one also need to replace sort() by stable_sort().
comment:3 in reply to: ↑ 2 ; follow-up: ↓ 4 Changed 4 years ago by fbossen
Replying to hanhuang:
Replying to fbossen:
Yes, it would make sense to use stable_sort in these cases for consistency. Presumably the arrays are small enough such that no impact on runtime is expected.
What about GeoComboCostList::sortByCost ?
Yes, the sortByCost one also need to replace sort() by stable_sort().
Can you submit a merge request?
comment:4 in reply to: ↑ 3 Changed 4 years ago by hanhuang
Sure. A merge request !2022 was just submitted.
Replying to fbossen:
Can you submit a merge request?
comment:5 Changed 4 years ago by fbossen
- Milestone VTM-12.0 deleted
- Resolution set to fixed
- Status changed from new to closed
- Version set to VTM-12.0
Yes, it would make sense to use stable_sort in these cases for consistency. Presumably the arrays are small enough such that no impact on runtime is expected.
What about GeoComboCostList::sortByCost ?