> However, C on LLVM or GCC should probably be considered the “upper bound” when it comes to how well a program can be optimized, and thus the benchmark for any performance measurement.
Is it? Isn't it rather the case that C is too low level to express intent and (hence) offer room to optimize? I would expect that a language in which, e.g. matrix multiplication can be natively expressed, could be compiled to more efficient code for such.
I would rather expect, that for compilers which don't optimize well, C is the easiest to produce fairly efficient code for (well, perhaps BCPL would be even easier, but nobody wants to use that these days).
> I would expect that a language in which, e.g. matrix multiplication can be natively expressed, could be compiled to more efficient code for such.
That's exactly the question we would hope to answer with such an experiment. Given that your language received sufficient investments to implement an optimal LLVM adaptation (as C did), we would then expect your language to be significantly faster on a benchmark heavily depending on matrix multiplication. If not, this would mean that the optimizer can get away with any language and the specific language design features have little impact on performance (and we can use them without performance worries).
Rochus, your point about LLVM and the 'upper bound' of C optimization is a bit of a bitter pill for systems engineers. In my own work, I often hit that wall where I'm trying to express high-level data intent (like vector similarity semantics) but end up fighting the optimizer because it can't prove enough about memory aliasing or data alignment to stay efficient.
I agree with guenthert that higher-level intent should theoretically allow for better optimization, but as you said, without the decades of investment that went into the C backends, it's a David vs. Goliath situation.
The 'spiraling complexity' of LLVM you mentioned is exactly why some of us are looking back at leaner designs. For high-density data tasks (like the 5.2M documents in 240MB I'm handling), I'd almost prefer a language that gives me more predictable, transparent control over the machine than one that relies on a million-line optimizer to 'guess' what I'm trying to do. It feels like we are at a crossroads between 'massive compilers' and 'predictable languages' again.
Now I'm no expert in that matter, but the fs deduplicators I've seen were block, not file, based. Those can clearly not use the file length as they are blissfully unaware of files (or any structure for that matter). Those use a rather expensive hash function (you really want to avoid hash collisions), but (at least some ten years ago) memory, not processing speed, was the limiting factor.
Ah, right, thanks. I now dimly recall some old project realizing fs-snapshots using hard links, which one could consider some sort of deduplication as well.
> I think you are thinking of block level online deduplicators that are integrated into the file system?
> Ah, right, thanks. I now dimly recall some old project realizing fs-snapshots using hard links, which one could consider some sort of deduplication as well.
Most modern CoW filesystems also allow you to mark two files as duplicates, but without sharing subsequent mutations between them. Rmlint supports that, too.
Btw, I'm working on adding deduplication to Bcachefs, and because it's extent-based and not blockbased, the logic will look a lot more like rmlint than what you described.
> Linux still doesn't have anywhere near as nice and cohesive as Group Policy, Active Directory etc.
I take your word for it (I know of Kerberos and LDAP and Netscape and Sun trying to make such palatable, but clearly haven't followed that in the last quarter-century).
That assumes however the server to be currently MS Windows. For government agencies, I'd rather expect some Mainframe to be (and remain) in place. Surely IBM (or here rather Groupe Bull) has user authentication/authorization figured out (more than half a century ago, methinks).
I puzzles me to no end why the typical office clerk should care about the OS at all. I understand that secretaries will be trained on MS Word and will then have a strong preference to use such (or at least something which very closely resembles it). Same for accountants with Excel. But clerks in e.g. Revenue Service? Those I expect to interact (perhaps these days via a Web interface) with custom software. Why would those ever see a 'Start' button or somesuch?
That hasn't been my experience working in Corporate America at all. Everyone gets a company laptop and they use it for whatever they want. Whether that's Excel, Google Sheets, or Netflix at home.
People think company hardware is their personal hardware and they have preferences.
I had a company phone once (terrible experience) and I'd routinely get txts from random services and people outside our company thinking it was the previous owner. The last employee who had used it mixed company use and personal use.
Multiple and dissimilar redundancy is nice and all that, but is there a manual override? Apollo could be (and at least in Apollo 11 and 13 it had to), but is this still possible and feasible? I'd guess so, as it's still manned by (former) test pilots, much like Apollo.
No, something is funny here. In the previous submission (https://news.ycombinator.com/item?id=47680023) the only (competently) criticizing comment (by jeffbee) was downvoted into oblivion/flagged.
Well he veered off of the technical and into the personal so I'm not surprised it's dead. But yeah something feels weird about this comment section as a whole but I can't quite put my finger on it.
I think rather than AI it reminds me of when (long before AI) a few colleagues would converge on an article to post supportive comments in what felt like an attempt to manipulate the narrative and even at concentrations that I find surprisingly low it would often skew my impression of the tone of the entire comment section in a strange way. I guess you could more generally describe the phenomenon as fan club comments.
There are a few glazing comments there too though.
> Well he veered off of the technical and into the personal so I'm not surprised it's dead.
I don't know what he posted, but it is easy to see how a small fan group around Laurie can form?
She is an attractive girl not afraid to be cute (which is done so seldom by women in tech that I found a reddit thread trying to triangulate if she is trans. I am not posting that to raise the question, but she piques peoples interest) plus the impressively high effort put into niche topics PLUS the impressively high production value to present all that.
it was flagged because it was unnecessarily rude. nothing "funny" going on (with that comment chain at least).
i would note that it also appears to be wrong, reading laurie's reply, though i am not an expert. rude + wrong is a bad combo.
the next comment by jeffbee is also quite rude, and ignores most of laurie's reply in favor of insulting her instead. i dont think it is a mystery why jeffbee's comments were flagged...
Indeed. And only for certain DRAM refresh strategies. I mean, it's at least conceivable that a memory management system responsible for the refresh notices that a given memory location is requested by the cache and then fills the cache during the refresh (which afaiu reads the memory) or -- simpler to implement perhaps -- delays the refresh by a μs allowing the cache-fill to race ahead.
Years ago, there was a project combining Debian with the kernel from FreeBSD. That never made sense to me and the project seems to have died meanwhile. More sensible, IMHO, might be to bolt the FreeBSD user space unto the Linux kernel. That way one would get fairly broad and current hardware support and could still enjoy a classic Unix look&feel and stable ABI.
> More sensible, IMHO, might be to bolt the FreeBSD user space unto the Linux kernel.
A lot of BSD utilities that are not POSIX has really close interaction with the kernel. OpenBSD’s *ctl binaries are often the user-facing part of some OS subsystem. Linux subsystem often expose a very complex internal that you need to use some other project to tame down
> More sensible, IMHO, might be to bolt the FreeBSD user space unto the Linux kernel.
Chimera Linux is doing something like this, although without aiming for the full BSD experience, just utilising its core userland [1]. The project is in an alpha stage.
IMHO the biggest advantage that Debian/kFreeBSD would have had would be first-class ZFS support. You can use ZFS with Debian today, but the license problem means it only gets supported through DKMS, which is a pain; a FreeBSD-based Debian could ship binary packages for ZFS that just worked out of the box.
Considering the amount of Linux distros based on Debian, it is truly a shame that Debian/kFreeBSD stagnated. We could have had Proxmox/kFreeBSD with support for ZFS Boot environments! The evolution of FreeNAS/TrueNAS demonstrates things have been going in the opposite direction.
Moreover, many laptops working on Linux perfectly, are not Ubuntu certified. Lenovo Legion series generally works well, but it is not in the Ubuntu list. Id we'd make a list of all 8/10 or more compatible laptops, it would be huge.
Prompted a grin. Then however
"If we wanted to test this using directed testing we would need to test for all 2^32 input combinations, which sounds like a terrible idea …
Is it? Isn't it rather the case that C is too low level to express intent and (hence) offer room to optimize? I would expect that a language in which, e.g. matrix multiplication can be natively expressed, could be compiled to more efficient code for such.
I would rather expect, that for compilers which don't optimize well, C is the easiest to produce fairly efficient code for (well, perhaps BCPL would be even easier, but nobody wants to use that these days).
reply