Skip to content

shibatch/sleef

Repository files navigation

SLEEF - SIMD Library for Evaluating Elementary Functions

TPDS

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.

Linux

Windows

Mac

gcc

llvm

MSVC

Clang

MinGW

Cygwin

Clang

GCC

x86_64

RISC-V 64

N/A

N/A

N/A

N/A

N/A

N/A

AArch64

POWER

N/A

N/A

N/A

N/A

N/A

N/A

S390X

N/A

N/A

N/A

N/A

N/A

N/A

✔ : Tested on CI, ❓ : Not tested, ❌ : Not supported

Support status of each vector extension

x86_64

SSE2

Experimental support, seeking sponsorship

x86_64

AVX2

Mainline support

x86_64

AVX512F

Mainline support

RISC-V

RVVM1

Experimental, seeking sponsorship

RISC-V

RVVM2

Experimental, seeking sponsorship

AArch64

AdvSIMD

Mainline support

AArch64

SVE

Unmaintained

PowerPC

VSX

Experimental, seeking sponsorship

PowerPC

VSX3

Experimental, seeking sponsorship

S390

VXE

Experimental, seeking sponsorship

S390

VXE2

Experimental, seeking sponsorship

Unmaintained and experimental 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.

  • Ninja

  • Git

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.

  1. Check out the source code from our GitHub repository

git clone https://github.com/shibatch/sleef
  1. Make a separate directory to create an out-of-source build

cd sleef && mkdir build && cd build
  1. 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.

  1. Run make to build the project

cmake --build . -j --clean-first
  1. Run tests using ctests

ctest -j `nproc`

For more detailed build instructions please refer to our web page.

How to cross-compile SLEEF

For more detailed please refer to cross-compile SLEEF

Install SLEEF

From source

Assuming following instructions were followed.

  1. 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 LICENSE.txt or copy at http://www.boost.org/LICENSE_1_0.txt. Contributions to this project are accepted under the same license.

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. 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 Code of Conduct or its introduction video. For reuse of this sustainability statement, see SUSTAINABILITY.md.

Copyright © 2010-2025 SLEEF Project, Naoki Shibata and contributors.