== SLEEF - SIMD Library for Evaluating Elementary Functions
image:http://img.shields.io/badge/DOI-10.1109/TPDS.2019.2960333-blue.svg[TPDS, link=https://ieeexplore.ieee.org/document/8936472]
SLEEF is a library that implements vectorized versions of C standard
math functions. This library also includes DFT subroutines.
== Supported environment
=== Test matrix
The following table summarizes currently supported OSes and compilers.
[cols=“1,1,1,1,1,1,1,1,1”]
|===
| 2+|Linux 4+|Windows 2+|Mac
| |gcc |llvm |MSVC |Clang |MinGW |Cygwin |Clang |GCC
|x86_64 |✔ |✔ |✔ |✔ |✔ |❓ |✔ |❓
|AArch64 |✔ |✔ |❌ |❌ |❌ |❌ |✔ |❓
|===
✔ : Tested on CI, ❓ : Not tested, ❌ : Not supported
=== Support status of each vector extension
[cols=“1, 1, 1”]
|===
| x86_64 | SSE2 | Experimental support, seeking sponsorship
| x86_64 | AVX2 | Mainline support
| x86_64 | AVX512F | Mainline support
| AArch64 | AdvSIMD | Mainline support
| RISC-V | RVVM1 | Unmaintained
| RISC-V | RVVM2 | Unmaintained
|===
Unmaintained features may be removed without notice.
Unmaintained features are not tested and may not build correctly.
== How to build SLEEF
The library itself does not have any additional dependency.
In order to build SLEEF, you need CMake 3.18+, and C and C++ compilers of the same version.
It is also recommended to have the following tools.
https://github.com/shibatch/tlfloat[TLFloat] is automatically downloaded if no suitable version is found on your system.
Some tests require:
- libssl and libcrypto, that can be provided by installing openssl.
- libm, libgmp and libmpfr
- libfftw.
The build procedure is as follows.
[arabic]
. Check out the source code from our GitHub repository
…
git clone https://github.com/shibatch/sleef
…
[arabic, start=2]
. Make a separate directory to create an out-of-source build
…
cd sleef && mkdir build && cd build
…
[arabic, start=3]
. Run cmake to configure the project
…
cmake … -DCMAKE_INSTALL_PREFIX=…/…/install
…
By default this will generate shared libraries. In order to generate
static libraries, pass option -DBUILD_SHARED_LIBS=OFF.
For more verbose output add option -DSLEEF_SHOW_CONFIG=ON.
[arabic, start=4]
. Run make to build the project
…
cmake --build . -j --clean-first
…
[arabic, start=5]
. Run tests using ctests
…
ctest -j nproc
…
For more detailed build instructions please refer to
https://sleef.org/compile.xhtml#preliminaries[our web page].
== How to cross-compile SLEEF
For more detailed please refer to
https://sleef.org/compile.xhtml#cross[cross-compile SLEEF]
== Install SLEEF
=== From source
Assuming following instructions were followed.
[arabic, start=6]
. Install to specified directory <prefix>
…
cmake --install .
…
=== Uninstall
In order to uninstall SLEEF library and headers run
…
sudo xargs rm -v < build/install_manifest.txt
…
== License
The software is distributed under the Boost Software License, Version
1.0. See accompanying file link:./LICENSE.txt[LICENSE.txt] or copy at
http://www.boost.org/LICENSE_1_0.txt. Contributions to this project
from individual developers and small organizations are accepted under
the same license. For contributions from corporate users, please refer
to link:./CONTRIBUTING.md[CONTRIBUTING.md].
==== Building a Sustainable Future for Our Open Source Projects
We believe that Free and Open Source Software (FOSS) is a wonderful
ecosystem that allows anyone to use software freely. However, to
maintain and enhance its value over the long term, continuous
maintenance and improvement are essential.
Like many FOSS projects, we face the challenge that long-term
sustainability is difficult to achieve through the goodwill and
efforts of developers alone. While the outputs of open-source projects
are incorporated into the products of many companies and their value
is rightfully recognized, the developers who create these outputs are
not always treated as equal partners in the business world.
A license guarantees the “freedom to use,” but the spirit of the FOSS
ecosystem is based on a culture of mutual respect and contribution
built upon that freedom. We believe that accepting the “value” of a
project’s output while unilaterally refusing dialogue with its
creators simply because they are individuals undermines the
sustainability of this ecosystem. Such companies should not turn a
blind eye to the reality that someone must bear the costs to make the
cycle sustainable.
This issue is not just about corporations; it reflects a deeper
cultural expectation within the FOSS ecosystem itself. Over time, we
have come to take for granted that everything in open source should be
provided for free - not only the code, but also the ongoing effort to
maintain and improve it. However, FOSS licenses guarantee the freedom
to use and modify software; they do not impose an obligation on
developers to offer perpetual, unpaid maintenance. When this
distinction is overlooked, maintainers can end up burdened with work
that was never meant to be an open-ended personal commitment. Such an
imbalance not only discourages openness, but also undermines the
sustainability of an ecosystem that has become a vital part of modern
society.
To explain the phenomenon occurring across the entire ecosystem:
Developers write code they find useful and release it as FOSS. It
gains popularity, and soon large corporations incorporate it into
their products, reaping substantial profits. Requests for new features
and fixes flood in, yet no financial support accompanies
them. Eventually, the maintainer realizes there is no personal or
professional benefit in responding to these unpaid demands. The skills
required to develop popular FOSS are often in high demand in other
fields as well. Ultimately, the maintainer burns out and the project
is abandoned. This is the unsustainable cycle we are tackling.
Within this unsustainable cycle, adopting FOSS into products while
fully aware of this situation is hardly beneficial for either
companies or the society at large. To make the cycle sustainable,
everyone must recognize the reality that someone must bear the costs,
and these costs are equivalent to what companies would need to develop
and maintain comparable products. This project specifically requests
companies profiting from our deliverables to contribute to maintaining
the project.
To be clear, this is not a request for charity; it is a proposal
to manage the operational risk. This is a systemic challenge
originating not from the developers, but from within the organizations
that consume and whose business continuity depends on FOSS. Should a
project be abandoned due to this unresolved problem, the primary
victims will be you, the company that built its product on top of an
unmaintained foundation, not the developers who can move on to other
opportunities.
==== Our Request for Support
We request ongoing financial support from organizations that
incorporate our project’s deliverables into their products or services
and derive annual revenue exceeding US $1 million from those
products and services, to help cover the costs of maintenance and the
development of new features. While this support is not a legal
obligation, let us be clear: the license is a grant of permission to
use our work, not a service contract obligating us to provide
perpetual, unpaid labor. We consider it a fundamental business
principle that to profit from a critical dependency while contributing
nothing to its stability is an extractive and unsustainable practice.
It is also crucial to recognize what “maintenance” truly entails. In a
living software project, it is not merely about preserving the status
quo of the current version. It is the continuous effort that leads to
security patches, compatibility with new environments, and the very
features that define future versions. Therefore, to claim satisfaction
with an older version as a reason to decline support, while
simultaneously benefiting from the ongoing development that produces
newer, better versions, is a logically inconsistent position.
This support must not be intended to benefit any particular company,
but must support maintaining the project as a shared infrastructure
that benefits all users and the broader community. Furthermore,
this threshold is designed so that individual developers,
small-scale projects, and the majority of our users are not asked to
pay, while seeking appropriate support from companies that derive
significant value from our project.
We understand that corporate procurement processes were not designed
with FOSS sustainability in mind. We are committed to finding a
practical path forward, but your partnership is essential in
structuring a financial relationship that aligns with your standard
corporate procedures. We simply ask for fairness: do not demand
contractual terms from maintainers that your own legal department
would refuse to accept. Our mutual goal is to treat this partnership
as a conventional operational expense, removing your internal barriers
and making sustainability a straightforward business practice.
Our goal is to maintain this project stably over the long term and
make it even more valuable for all users. In an industry where many
projects are forced to abandon FOSS licenses, our preference is to
continue offering this project under a true open-source
license. However, the long-term viability of this FOSS-first approach
depends directly on the willingness of our commercial beneficiaries to
invest in the ecosystem they rely on. We hope our collaborative
approach can contribute to shaping a more balanced and enduring future
for FOSS.
For details, please see our
https://github.com/shibatch/nofreelunch?tab=coc-ov-file[Code of
Conduct] or its https://youtu.be/wsh2yKGwK4s[introduction video]. For
reuse of this sustainability statement, see
link:SUSTAINABILITY.md[SUSTAINABILITY.md].
Copyright © 2010-2025 SLEEF Project, Naoki Shibata and contributors.
评论