Re: Have we become too Intel x64 centered?

From: Edward Diener (eldiener_at_[hidden])
Date: 2021-01-27 17:03:42

On 1/27/2021 3:41 AM, Andrey Semashev via Boost wrote:
> On 1/27/21 7:38 AM, Edward Diener via Boost wrote:
>> On 1/25/2021 6:08 PM, Gavin Lambert via Boost wrote:
>>> On 26/01/2021 10:53 am, Edward Diener wrote:
>>>> Please name the Boost low level libraries which have specific code 
>>>> aimed at the platform/architecture combination. I am not talking 
>>>> about code for just Mac or Linux or Solaris or Windows but code that 
>>>> actually does something different when run on Intel or ARM or 
>>>> AArch64 etc. I still imagine that if such Boost libraries exist 
>>>> there are still very, very few Boost libraries with dependence on 
>>>> such code. I am not arguing that testing on non-Intel is in any way 
>>>> wrong but simply that very, very few libraries should be impacted by 
>>>> different architectures in any way.
>>>
>>> Boost.Atomic (and consequently Boost.Lockfree too) is the obvious one 
>>> (that Niall already hinted at), but parts of Boost.Thread also apply.
>>>
>>> Add to that list other low-level libraries such as Boost.Endian, 
>>> Boost.Coroutine[2], and Boost.Fiber as well.
>>>
>>> There are also some surprise gotchas in other libraries that do their 
>>> own spinlocks or pointer-packing, such as Boost.SmartPtr and likely 
>>> others.
>>>
>>> Meanwhile other libraries like Boost.Serialization (and consumers of 
>>> same) also make their own assumptions about things like endianness 
>>> and type structure, which may not matter too much in isolation but 
>>> becomes very important if you're intending to use it as a portable 
>>> network or disk format.
>>
>> I think then it is important for the libraries in which some of the 
>> code is tailored to a platform/architecture to test on other 
>> platform/architectures than Intel, but for the large number of Boost 
>> libraries which have no direct dependencies on a platform/architecture 
>> I do not see that it is of much importance. Simply because library XXX 
>> uses Boost.SmartPtr does not mean that testing on ARM is going to show 
>> anything of use for library XXX, which testing Boost.SmartPtr on ARM 
>> would not itself show.
> 
> Memory ordering correctness cannot be tested in the low level libraries, 
> it must be tested at the place of use, i.e. in the downstream libraries.
> 
> Assumptions about alignment, endianness and overflow semantics and FP 
> specifics are also not limited to lower level libraries and tend to crop 
> up at any level.

Granted ! But I think that the vast majority of Boost libraries do not 
deal in these issues. For the ones that do testing with different 
platform/architecturs is important.