The `new` thing is the range-splitting which achieves the floor division for negative inputs (eg. sign-selected for 60% of divisors, and the negative/positive bump for the remaining 20%/20% of cases each).

Comments URL: https://news.ycombinator.com/item?id=50256409

Points: 88

# Comments: 5

Comments URL: https://news.ycombinator.com/item?id=49710096

Points: 5

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49596678

Points: 9

# Comments: 0

I have a mobile-friendly web-app where you can practice this technique, just click the link in the page's nav: "Weekle - Weekday Guessing Game"

I would not normally spend such effort, but in this case I felt that the functions were too hard to understand without the visual aid, and too difficult to customise without the Function Explorer.

Then I think I just got a bit carried away with the detail.

Comments URL: https://news.ycombinator.com/item?id=49328331

Points: 5

# Comments: 0

(The link in the submission is incorrect; apologies for the confusion.)

The article outlines the technique, shows related developments before and after its creation, and includes an interactive, human-verifiable "proof".

Comments URL: https://news.ycombinator.com/item?id=46238801

Points: 2

# Comments: 2

It might also come into play if developing SIMD alternatives for batch date processing, as one can have more lanes with 16-bit. I plan to make a blog post covering SIMD and if 16-bit algorithms have reasonable performance then that will be covered.

When I started the blog series, I expected the first article to be the most noteworthy, with the 2nd and 3rd being lesser supplementary topics.

Now that the 3rd blog post ended up with a much larger result than I was expecting, it stands on its own and could do with some editing as you suggest.

Displaying the months like the following helps see the regularity at a glance. Columns 1, 3 and 5 are the long months, others being shorter:

  +-----+-----+-----+-----+-----+
  | 31  | 30  | 31  | 30  | 31  |
  |  I  | II  | III | IV  |  V  |
  | MAR | APR | MAY | JUN | JUL |
  |-----+-----+-----+-----+-----+
  | 31  | 30  | 31  | 30  | 31  |
  | VI  |VII  |VIII | IX  |  X  |
  | AUG | SEP | OCT | NOV | DEC |
  +-----+-----+-----+-----+-----+
  | 31  |28/29|
  | XI  |XII  |
  | Jan | FEB |
  +-----+-----+

[1] https://www.benjoffe.com/fast-date

I was fortunate enough to be programming on an ARM based device, which meant that the terms (x * 4 + 3) strongly stood out to me as highly inefficient, being 2 cycle prep for the more important division. On x64 computers, those two operations are calculated in only one operation by using the 'LEA' assembly instruction (which I wasn't aware of at the time), and so others using that type of computer might not have felt this step needed any simplification.

I tried everything under the sun to get rid of these steps. The technique noted in the article of using the year 101 BC was for a long time my strongest candidate, you can view the implementation of that attempt at the link below [1].

An epoch of 101 BC still meant that there was extra work required to re-normalise the timeline after the century calculation, but it was only a single addition of 365 in the calculation of `jul`. The explanation of how this works is probably a whole blog post in itself, but now that this algorithm has been discarded it's not worth the time to explain it fully.

I also had the year-modulus-bitshift technique developed at that time, but it couldn't be integrated cleanly with any of my algorithm attempts yet. My plan was to simply document it as an interesting but slower concept.

I don't know what sparked the idea of going backwards other than immersing myself deeply in the problem in my spare time for about a month. It finally came to me one evening, and I thought it was only going to save 1-cycle, but when it also meant the year-modulus-bitshift could be utilised, the entire thing fit together like a glove and the speed collapsed down from 20% time saving to 40%.

[1] https://github.com/benjoffe/fast-date-benchmarks/blob/218356...

While it is rarely a bottleneck, it is a very frequently run algorithm, and thus has attracted a lot of attention over the years.

In 2021, Cassio Neri and Lorenz Schneider developed the Neri-Schneider algorithm, which was a major breakthrough in this niche area.

Lately, I have been studying this function deeply, and found what I believe may be the last remaining substantial improvements achievable on current hardware. The gains come mainly from counting dates backwards, and from reducing the number of multiplications from 7 to 4.

Adoption will depend on whether library maintainers consider the performance benefit to outweigh the readability. If this is rejected on readability grounds, then in those cases my algorithm outlined in Article 1 (linked in the blog post navigation) is likely to be simpler and faster than what almost all existing libraries are currently doing.

I found this a very interesting challenge to work on, and I believe some of the techniques outlined may be applicable to other areas of optimisation.

Comments URL: https://news.ycombinator.com/item?id=46040319

Points: 3

# Comments: 0

It achieves a 30–40% speed improvement on x86-64 and ARM64 (Apple M4 Pro) by reversing the direction of the year count and reducing the operation count (4 multiplications instead of the usual 7+).

Paper-style explanation, benchmarks on multiple architectures, and full open-source C++ implementation.

Comments URL: https://news.ycombinator.com/item?id=46020193

Points: 395

# Comments: 94

Comments URL: https://news.ycombinator.com/item?id=45796582

Points: 5

# Comments: 1

If you don't have time to read, you may want to quickly check "Appendix A" for the “Smoitus” chart to see visually how the timezone alignment systems works, and "Section 5: Equation of Time (Smoital System)" to see how well this system tracks solar time.

Comments URL: https://news.ycombinator.com/item?id=45023054

Points: 2

# Comments: 1