[Meta-issue] Fix the FORM5 regressions

[tueda]

Update: 2024-03-15

This is the meta issue to track regressions introduced in 5.0.0-beta. To be updated occasionally.

Known regressions

• [ ] #474

Tests disabled in CI

Currently, the test cases Diagrams_1 to Diagrams_4 are temporarily disabled to allow the CI process to pass.

• 494

To run the disabled tests, use the -f option of check.rb:

./check/check.rb build/sources/form -s -f 'Diagrams_*'

Merged PRs that are likely to have no side effects or negligible performance regressions

We think these changes are OK, but if you encounter any noticeable regressions on the master branch when comparing it to version 4.3.1, please let us know.

• 477: This fixes crashes in code optimization. It is "phenomenologically" correct.

• 482: This fixes PolyRatFun bugs (giving wrong answers) at the cost of hopefully negligible performance loss.

• 490: This fixes crashes due to argument wildcards matching with more than 8191 arguments. We hope there are no oversights, though it was too ancient code without any comments.

• 493: This fixes data races in TFORM thread statistics, which become apparent when Print +f is used with the -F command-line option. Probably there are no oversights, though it is not well-tested in complicated situations (e.g., stage 4 sort).

[tueda]

I will start merging postponed PRs that are complete and likely to have no or negligible side effects such as #477, #482 and #490. They will be listed in this issue as those that could potentially introduce some regressions (albeit unlikely). In this way, test users can easily access versions incorporating the latest PR merges, with awareness of potential regressions.

[jodavies]

Before FORM 5, I would like to resolve at least the following. For some of these I know roughly what the problem is, but would benefit from a discussion with Jos to check that I really understand things. The workshop in May would be a good place to do this I expect.

230 :white_check_mark:

292 :white_check_mark:

420 and #484 :question:

468 :white_check_mark:

Maybe we should also start to work through the open issues and close + tag as "question" or "wontfix" where appropriate, to clean up the issue tracker a bit.

[tueda]

Do we need another 5.0 beta version (and a 4.3 version with backported bug fixes) before the workshop? This could serve as a good starting point for discussions at the workshop.

If the workshop successfully resolves the issues you mentioned, we could then proceed with another (beta) release afterwards.

Related to the tags: The question and good first issue tags are abused in ways that differ from the GitHub defaults: the former had been used for "questions by users" (though I haven't put question tag recently because of this difference) and an example of the latter is https://github.com/vermaseren/form/issues/300. We might consider creating new tags with more specific meanings. At least, adding a documentation tag (as the default meaning) would be good.

[jodavies]

I am not sure a specific beta "release" is necessary for the workshop. The current master branch is in reasonable shape to work from (diagram generator issues aside), and the results of the workshop can inform what a final beta of FORM 5 should look like before a testing period and final release.

We should also look through the issues labelled as "enhancement" and think about what would be good to include in FORM 5. (Personally I would like to look at #436 at least).

Since "question" has been used previously to tag questions about the use of FORM, my opinion would be to just keep that convention now.

[jodavies]

Here is a bit of a summary of some discussions at the workshop.

Diagrams/topologies:

• The new diagrams should have all of the functionality of the old topologies, which is there for backwards compatibility. But it could also be removed from FORM5. Then the open bugs regarding this are "resolved".
• A good set of tests for diagrams_ is still needed before release, though.

32bit builds:

• No one at the workshop uses or knows anyone who uses 32bit builds. Remove support from FORM5.
• Various tests already don't work in 32bit mode, and the float mode doesn't seem to work either.
• FORM 4.3.1 (and 4.3.2) can keep the 32bit build in its current form?

Parform:

• Similarly, no one uses or knows anyone who uses Parform these days. Support could be removed from FORM5 in principle.
• This is a larger change to the code than removing 32bit support, though, and it would be harder to "put back".
• My opinion would be, for a first step, to break the build: ("--enable-parform" just prints a deprecation message and instructs the user to open an Issue. Maybe add "--enable-parform-force" in the mean time?). If nobody complains by "FORM 5.1", remove it?

A few easy-seeming ideas which have been/could be implemented for FORM5:

• Read-only tablebases (#531)
• More constants for float mode (#532)
• Split sort allocation and better debug info on crash (#526 #529)
  • check performance with benchmarks: no impact.
• Pre-processor command to re-alloc large+small buffers: drops resident set usage if the user knows the program becomes lighter in the following modules, avoid possible unnecessary swapping (@msloechner).
  • (If no performance impact, could just do this automatically on every .sort: benchmark this It is slower.). (#537)
  • Don't write large patch on small buffer sort, if it has sufficient space remaining (@benruijl)
    • I have implemented this one, but so far see no performance improvement.
  • Try to find equal terms early in Compare1, by using memcmp (@benruijl)
    • have implemented this one, but so far see no performance improvement.
  • PolyRatFun expand: mode which expands to absolute, rather than relative, depth.
  • Zstd compression: @magv pointed out that there is a "zlib wrapper", allowing zstd use with very little change to FORM's code. Benchmark this.

Harder-seeming changes, for the future:

• Workspace realloc: harder to catch infinite loops. But nice for heavy users of the optimizer (eg, pySecDec @magv). Maybe user-configurable setting, off by default?
  • For the optimizer only, suffices to have #535)
• Use FLINT for polyratfun operations.
• Remove maxtermsize limitation (or allow it to be much larger) -- small buffer becomes an array of dynamically allocated regions. IObuffer sizes need to be checked on term-read from patches. TODO: find the many other places where this will cause problems...
• Parallelize processing on expr definition, save file load, copyspectator (tform).

Please comment, if I have forgotten anything.

[tueda]

Thanks for summarising the discussions!

How about Windows? Is there no need to run FORM on any platform other than Linux/macOS x86_64?

[jodavies]

Ah, indeed we discussed this also: people think that it is nice, particularly for students, if form run on windows. At the very least, we should make sure that it works OK under WSL.

As for proper windows support, this basically comes down to how close you think you are with your branch. Personally, I have no development experience at all under windows.

[tueda]

Actually, the Windows version doesn't use any Windows APIs (except for timers, I think). It simply maps all FORM IO routines to the corresponding C standard library functions:

https://github.com/vermaseren/form/blob/83e3d4185efca2e5938c665a6df9d67d6d9492ca/sources/form3.h#L517-L533

You don't need to know Windows (unless you want to implement missing functionalities based on special POSIX routines).