Issue #16487 has been updated by naruse (Yui NARUSE).


The topic is
* portability between architectures
* portability in a architecture
* maintenanceability

## Portability between architectures

Though some compilers provides intrinsics for SIMD instructions, introducin=
g SIMD needs more `#ifdef`s.
It makes code less maintenanceability.

## portability in a architecture

People sometimes build a binary package. If a binary package uses machine d=
ependent instructions the binary will cause SEGV.

For example all x86_64 CPUs implements SSE and SSE2. Therefore they are pot=
able for x86_64 machines.
But earlier CPUs doesn't have SSE4 instructions.
If we introduce SSE4 optimizations, we need some consideration and treatmen=
t.

## Maintenanceability

Introducing SIMD will make maintenanceability worse.
It may be acceptable but it needs to show that the benefit of the optimizat=
ion is larger than the cost of maintenanceability.

----------------------------------------
Misc #16487: Potential for SIMD usage in ruby-core
https://bugs.ruby-lang.org/issues/16487#change-83703

* Author: byroot (Jean Boussier)
* Status: Open
* Priority: Normal
* Assignee: =

----------------------------------------
### Context

There are several ruby core methods that could be optimized with the use of=
 SIMD instructions.

I experimented a bit on `coderange_scan` https://github.com/Shopify/ruby/pu=
ll/2, and Pavel Rosick=FD experimented on `String#strip` https://github.com=
/ruby/ruby/pull/2815.

### Problem

The downside of SIMD instructions is that they are not universally availabl=
e.
So it means maintaining several versions of the same code, and switching th=
em either statically or dynamically.

And since most Ruby users use precompiled binaries from repositories and su=
ch, it would need to be dynamic if we want most users to benefit from it.

So it's not exactly "free speed", as it means a complexified codebase.

### Question

So the question is to know wether ruby-core is open to patches using SIMD i=
nstructions ? And if so under which conditions.

cc @shyouhei





-- =

https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=3Dunsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>