Toward SLEEF 4.0 Development

[shibatch]

We are going to release SLEEF 3.9 shortly.
After the release of SLEEF 3.9, we will start working on the release of SLEEF 4.0.

For SLEEF 4.0, the following policies will be adopted to reduce development and maintenance costs.

• Supported OS will be Ubuntu, Windows, and macOS.
  • We will support the architectures supported by the official and latest stable versions of these OSes
  • Supported compilers are only the latest versions of compilers officially used on these OSes.
  • Support for other operating systems and architectures will be provided only as long as sponsorship is provided.
• Some OSes, architectures, and compilers other than those listed above will continue to be supported on a voluntary basis, but their status will be experimental.
  • CUDA, clang, MinGW, Cygwin

The following features will be removed in SLEEF 4.0

• AArch32, i386, macOS/x86_64
• iOS, Android support
• The scalar lib (the library built with -DBUILD_SCALAR_LIB option will be removed. We will keep purec_scalar and purecfma_scalar support)
• Functionalities utilizing gcc vector extension
• AVX, FMA4, SSE3, SSE4.1 (support for SSE2 and AVX2 will be continued)
• printf hook in sleefquad

We will add new SLEEF features available only for C++ in the future.

• C++20-compatible compiler will be required
• Compatibility with the existing C API will be maintained, but linking to libc++ will be required
• TLFloat will be required
  • SLEEFquad's printf will be changed to use TLFloat functionality.

SLEEF 4.0 will adopt the new CoC.

If any company needs continued support for any of the above deprecated features, please let us know now.
Continuation of support will require sponsorship.

Companies that benefit from commercial use of the project's deliverables are asked to provide continued financial support for our project.

[shibatch]

In addition to the above, our policy is to remove, in principle, any code that cannot be tested within our project.
Sponsorship is required for the maintenance of such codes.

[shibatch]

Here is an addition.
Since AArch64 SVE is currently rarely used for general users, I would like to make its support status in version 4 unmaintained.

By “unmaintained” we mean that the project does not recommend incorporating the corresponding functionality into distributions, packages, etc.
In addition, the project does not guarantee to maintain API compatibility of unmaintained features at the time of minor version upgrades. Unmaintained features will not be tested on CI.

[shibatch]

At this time, SSE2 is the only vector extension in which FMA is not available, so all the functions with cinz, which do not utilize FMA, will be removed.
SSE2 will have limited support, and FMA computation will be handled by emulation using TLFloat.
If the CPU supports AVX2, the hardware FMA will be used by the dispatcher, so there will be minimal impact on the performance.
Since there are few CPUs that do not support AVX2 anymore, this will not be much of a problem.

SSE2 inline header will not be provided. As a result, web assembly support will be discontinued.

[shibatch]

Also, it goes without saying that we will not do any maintenance work on version 3 after version 4 is released.
If users want to continue to use version 3, and if maintenance is necessary, it must be handled entirely by the user.

If you have any requests to change the above policy, please tell us now.

[shibatch]

And I am also wondering if I could drop support for the so-called GNUABI.
Is this API still being used?
One way is to mark this experimental, and if people start complaining, I will put it back to the mainline support.

But I now decided to just drop this feature.

[shibatch]

I suspect the reason you feel this CoC hinders individual and non-profit projects is that the threshold for requesting financial support is set too low. I assume this threshold should be around US$1 million annually. Even that might be a bit too low. If sales of products incorporating FOSS project components exceed US$10 million per year, failing to support the FOSS project can only be viewed as exploitation.

[shibatch]

Then, I'd like to ask you what you specifically consider to be the fundamental problem. I believe the accounting issues are significant, and if we can resolve them, I think this problem will see major progress.

[shibatch]

I've published a new document. Please take a look if you'd like. I'll add this document to SLEEF in due course.

https://github.com/shibatch/SSRC/blob/master/SUSTAINABILITY.md

[ebhb010]

I've published a new document. Please take a look if you'd like. I'll add this document to SLEEF in due course.

https://github.com/shibatch/SSRC/blob/master/SUSTAINABILITY.md

Sorry to reply this late! I took a quick read and this looks fine to me.

[shibatch]

Today I've released yet another document, so please take a look.
Since it's quite long, you might want to have an AI read it and ask various questions about it.

https://github.com/shibatch/nofreelunch/blob/main/README.md

[shibatch]

Regarding the handling of deterministic functions, we would like to make the finz family of functions the standard.
In other words, the current non-deterministic functions will be removed, and finz-equivalent functions will become the standard functions .
Although there may be concerns about performance, we do not expect any significant impacts.

[shibatch]

Today, I have marked several vector extensions as experimental.
The extensions marked as experimental will be released as experimental if no sponsors appear by the time of the version 4.0 release.
I am planning to release version 4.0 in June.
There is still some time before then, but I will be concentrating on other projects.

[shibatch]

After the release of version 4.0, I plan to sequentially remove support for vector extensions for which sponsors remain undecided.

[shibatch]

I ask you to think carefully about who I am maintaining this project for.
At least, I am no longer directly benefiting from maintaining this project.

Those who wish this project to be maintained in the future must choose whether to sponsor the project or maintain the project themselves.

I will not give away the repository to anyone for free. I have no reason to do so.

As I have said many times, it is wrong to think that FOSS is maintained for free.
From now on, I will only maintain sponsored features and features that I really like. I will remove all other features.
If no sponsors will appear at all, the maintenance of this project will eventually be terminated.

Still, it is only a matter of paying for it, and since the cost is much lower than outsourcing to an external company, the only problem is with those who choose not to pay. If they are not willing to pay even that level of cost, it means that they are fine with their code being erased.

Companies do not notify the project when their patches are no longer needed. Thus, if they are left unattended, the code will become full of garbage. To prevent this and ensure the long-term survival of the project, it is necessary to charge an annual maintenance fee for the patches anyway. It is necessary for the sustainability of the project to quickly disassociate itself from companies that refuse to pay the maintenance fees.

[shibatch]

Recent developments

Overcoming barriers to Open Source procurement in the European Union
$4.15B invested in open-source generates $8.8T of value for companies
The Reality of Long-Term Software Maintenance

It's funny how a company that runs away from these issues that they should be the first to take responsibility for is so enthusiastic about DEI.

[shibatch]

Some of you may be thinking that project maintenance is easy since all we have to do is to approve PRs, so let me explain.

In order to keep up with maintenance, we need to maintain a CI environment. Currently, I run a CI environment primarily using Jenkins running at my house. Using an external service like GitHub Actions does not actually make CI environment operation much easier. This is because the settings of the external service change frequently, and the project settings need to be changed accordingly. Also, in most cases, the external service alone does not cover all the configurations needed for testing.

An external CI environment alone is not sufficient for the purpose of code changes. We need environments to execute the changed code. Thus, we need to maintain the execution environments anyway.

Also, it is rare that a PR we receive will pass all the tests immediately. We need to advise them how to pass the tests, and to do that we need to read and examine the code. This requires expertise on the project. We need to supplement the code as needed to maintain a balanced state across all architectures. Furthermore, if a new compiler fails to build for some reason, the user will only report the problem, but will not offer a solution. In that case, we will need to create a workaround. Of course, in addition to that, there are cases where an unknown bug is discovered and needs to be addressed.

Thus, there will be a reasonable workload on an ongoing basis, and in order to keep it that way, the decision is made that it is better to also do some development of new features and ask for sponsorship.

We cannot and will not offer the option of doing no development and only maintenance without sponsorship. Without sponsorship, we will have to eventually shut down our CI environment and end maintenance. In particular, if our CI environment is lost for any unforeseen reason, and if there is no sponsor at that point, we will not rebuild the environment and our service will be terminated.

And, if I write the above, some companies might say that they will provide an environment entirely in the cloud. However, cloud environments are usually complicated to manage accounts, have many restrictions, are slow, and are often not easy to use. In addition, we need to set up an external CI environment. Thus, in total, it is not much help.

Most importantly, I have no reason to continue to offer such services for free.

For the users, there are two choices: continue to use the old version by patching it yourself, or sponsor the project.

The fact that many people are visiting this repository and reading this message means that this project is still needed. Isn't it only natural that financial support should be supplied to such a project? And finally, please don't think that our project can be supported by an amount like a child's allowance. Think in terms of the salary your company pays your software engineers.

[shibatch]

Well, I explained the situation well, I said what I have to say, and I made it known properly, so if people complain about it later, it's their fault for complaining.
But once again, I will be removing various features when version 4 is released, but that is inevitable to keep the project alive as we do not have a sponsor. If they want us to maintain the functionality they need, they will need to sponsor the project.

[shibatch]

I'm not saying where, but isn't it not constructive to write something that criticizes the inconsistent maintenance of our project?
I have often explained that this project cannot be sustained in the long term without financial support.
I must then express my displeasure with the way someone complains in a manner that makes it sound as if it is our project's fault, without mentioning the root problem.

I now have the feeling that what is needed to solve this problem, more than anything else, is a change in the mindset of FOSS project participants.