Hacker Newsnew | past | comments | ask | show | jobs | submit | fweimer's commentslogin

Many of the conversions so far have been clearly faster. I don't think anything has been merged which shows a clear performance regression, at least not on CPUs with FMA support.

The bigger challenge is GPU/NPU. Branches for fast vs accurate path get costlier, among other things. On CPU this is less of a cost.

Most published libm on GPU/NPU side have a few ULP of error for the perf vs accuracy tradeoff. Eg, documented explicitly in the CUDA programming guide: https://docs.nvidia.com/cuda/cuda-programming-guide/05-appen... .

Prof. Zimmermann and collaborators have a great table at https://members.loria.fr/PZimmermann/papers/accuracy.pdf (Feb 2026) comparing various libm wrt accuracy.


using fma makes it possible to write faster libm functions, but going back to a 1 ulp world with the same fma optimizations would give you another 20% speedup at least. the other issue is that these functions tend to have much larger code size which tends not to be a significant problem in micro benchmarks, but means that in real applications you increase cache pressure allowing things down in aggregate

A lot of C++ programmers use C++ and garbage collection daily because their C++ compiler uses a tracing garbage collector.

https://gcc.gnu.org/onlinedocs/gccint/Type-Information.html


Which only appears relevant if you disregard critical differences like this:

The GCC garbage collector GGC is only invoked explicitly. In contrast with many other garbage collectors, it is not implicitly invoked by allocation routines when a lot of memory has been consumed. [1]

[1] https://gcc.gnu.org/onlinedocs/gccint/Invoking-the-garbage-c...


Limited controlled types probably come closest.

https://learn.adacore.com/courses/advanced-ada/parts/resourc...


I find this puzzling. It does not seem to allow to stack PRs on top of other people's PRs?

There is already an option to enable review comments on individual commits (see the API endpoint here: https://docs.github.com/en/rest/guides/working-with-comments...). Self-stacking PRs seem redundant.


Still feels like an alpha version right now. I'm sure they will add it later.

Graphite (which they seem to be inspired by) has frozen branches exactly for that use case:

https://graphite.com/blog/introducing-frozen-branches


This API leaves a comment, on the commit; not quite the same thing since in GH, several operations are tied to PRs and not to commits.

While I don't disagree about (2), my experience suggests that LLMs are biased towards generating code for future maintenance by LLMs. Unless instructed otherwise, they avoid abstractions that reduce repetitive patterns and would help future human maintainers. The capitalist environment of LLMs seems to encourage such traits, too.

(Apart from that, I'm generally suspect of evolution-based arguments because they are often structurally identical to saying “God willed it, so it must true”.)


I think they're biased toward code that will convince you to check a box and say "ok this is fine". The reason they avoid abstraction is it requires some thought and design, neither of which are things that LLMs can really do. but take a simple pattern and repeat it, and you're right in an LLM's wheelhouse.

I think CC originally did have producing physical items in mind. For example, one use case for the NC licenses for photos was that you can pay someone to make a print and frame it for you. This went sideways when Flickr offered to streamline the process because for many creators, NC means that no one (else) should be able make a profit using the work.

Employers might argue that such internal use and distribution would fall under the “exclusively under your behalf” clause in the GPLv3, which is inherited by the AGPLv3.

Oh, I guess it would. Ignore me.

And German law is more restrictive than U.S. copyright law, with fewer protections for content uploaders and service providers. There is also no concept of fair use that limits copyright.

I want Codeberg to succeed, but running an open code hosting platform (both in the sense that anyone can create an account, and the service source code is publicly available) in the European Union, and especially Germany, is extremely challenging from a legal perspective. Sadly, once they become successful and popular, they will have to implement all kinds of weird stuff, like proprietary scanners for potentially infringing content prior to publishing it.


This procedure only applies to copyright-infringing content, not to trafficking in circumvention devices. It seems that in this case, it's the latter.


But that's a different process, not the usual notice-and-takedown notice procedure. If it's consider a circumvention device, there is no way to file a counterclaim, among other things.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: