For what I use them for, the LLM market has become a two player game, and the players are Anthropic and Google. So I find it quite interesting that OpenAI is still the default assumption of the leader.
From what I've seen, 99% of people are using the free version of ChatGPT. Those who are using Claude are on the subscription, very often the $100/month one.
And at one point in the 90s, Internet=Netscape Navigator.
I see Google doing to OpenAI today what Microsoft did to Netscape back then, using their dominant position across multiple channels (browser, search, Android) to leverage their way ahead of the first mover.
That's funny, the way I see it is Microsoft put tens of billions of dollars behind an effort to catch Google on the wrong foot, or at least make Google look bad, but they backed the wrong guy and it isn't quite going to make it to orbit.
ChatGPT dominates the consumer market (though Nano Banana is singlehandedly breathing some life into consumer Gemini).
A small anecdote: when ChatGPT went down a few months ago, a lot of young people (especially students) just waited for it to come back up. They didn't even think about using an alternative.
When ChatGPT starts injecting ads or forcing payment or doing anything else that annoys its userbase then the young people won't have a problem looking for alternatives
That is different because all of the players I mentioned have credible, near-leading products in the AI model market, whereas nobody other than Google has search results worth a damn. I wouldn't recommend anyone squander their time by checking Kagi or DDG or Bing more than once.
I don't use google. Believe it or not, I get better results via Bing (usually via DDG, which is a frontend for Bing). But I asked the rhetorical question expecting the answer you gave. These people use ChatGPT only for the same reason you exclusively use Google.
codex cli with gpt-5.2-codex is so reliably good, it earns the default position in my book. I had cancelled my subscription in early 2024 but started back up recently and have been blown away at how terse, smart, and effective it is. Their CLI harness is top-notch and it manages to be extremely efficient with token usage, so the little plan can go for much of the day. I don’t miss Claude’s rambling or Gemini’s random refactorings.
Interestingly Claude is so far down in traffic it's below things like CharacterAI, it's the best model but it's something like 70% ChatGPT, 10% Gemini and Claude is only 1% or so
You avoid an unnecessary copy. Normal read system call gets the data from disk hardware into the kernel page cache and then copies it into the buffer you provide in your process memory. With mmap, the page cache is mapped directly into your process memory, no copy.
All running processes share the mapped copy of the file.
There are a lot of downsides to mmap: you lose explicit error handling and fine-grained control of when exactly I/O happens. Consult the classic article on why sophisticated systems like DBMSs do not use mmap: https://db.cs.cmu.edu/mmap-cidr2022/
I've never had to use mmap but this is always been the issue in my head. If you're treating I/O as memory pages, what happens when you read a page and it needs to "fault" by reading the backing storage but the storage fails to deliver? What can be said at that point, or does the program crash?
it allows the program to reference memory without having to manage it in the heap space. it would make the program faster in a memory managed language, otherwise it would reduce the memory footprint consumed by the program.
I don't fully understand the under the hood mechanics of mmap, but I can sense that you're trying to convey that mmap shouldn't be used a blanket optimization technique as there are tradeoffs in terms of page fault overheads (being at the mercy of OS page cache mechanics)
Tradeoffs such as "if an I/O error occurs, the program immediately segfaults." Also, I doubt you're I/O bound to the point where mmap noticeably better than read, but I guess it's fine for an experiment.
I think he's conveying that he doesn't know what he's talking about. buf[i] generates the same code regardless of whether mmap is being used. The first access to a page will cause a trap that loads the page into memory, but this is also true if the memory is read into.
I really have never been able to grasp how people who believe that forward-compatible data schema changes are daunting can ever survive contact with the industry at scale. It's extremely simple to not have this problem. "design for forwards-backwards compatible changes" is what every grown-up adult programmer does.
Static size, no deleting. Everyone already knew that you can make faster hash tables when they never need to be resized, but nobody bothers doing that because it is pretty useless or at best niche.
Well, not to be completely dismissive here... It's clearly a prototype project to try and make quadratic probing a thing.
I'm not convinced this methology is better than linear probing (which then can be optimized easily into RobinHood hashes).
The only line I see about linear hashes is:
> Linear jumps (h, h+16, h+32...) caused 42% insert failure rate due to probe sequence overlap. Quadratic jumps spread groups across the table, ensuring all slots are reachable.
Which just seems entirely erroneous to me. How can linear probing fail? Just keep jumping until you find an open spot. As long as there is at least one open spot, you'll find it in O(n) time because you're just scanning the whole table.
Linear probing has a clustering problem. But IIRC modern CPUs have these things called L1 Cache/locality, meaning scanning all those clusters is stupidly fast in practice.
Linear probing could get pretty nasty corner cases in a concurrent system. Particularly one where the table is “warmed up” at start so that 80% of the eventual size shows up in the first minute of use. If that table is big enough then pressure to increase the load factor will be high, leading to more probing.
If you have ten threads all probing at the same time then you could get priority inversion and have the first writer take the longest to insert. If they hit more than a couple collisions then writers who would collide with them end up taking their slots before they can scan them.
Cliff Click designed a hash table that does concurrent draining of the old table when resizing to a new one. I don’t think he did rate limiting on puts but there are other real time systems that amortize cleanup across all write allocations, which then spreads the cost in a way compatible with deadlines.
The big lie that you've all been sold is that Tesla has any kind of battery technology at all. Outside of repackaging Panasonic (in America) and other batteries (abroad), Tesla has dabbled in a few experiments and they all failed.
Once the compiler has generated a 32-bit relative jump with an R_X86_64_PLT32 relocation, it’s too late. (A bit surprising for it to be a PLT relocation, but it does make some sense upon reflection, and the linker turns it into a direct call if you’re statically linking.) I think only RISC-V was brave enough to allow potentially size-changing linker relaxation, and incidentally they screwed it up (the bug tracker says “too late to change”, which brings me great sadness given we’re talking about a new platform).
On x86-64 it would probably be easier to point the relative call to a synthesized trampoline that does a 64-bit one, but it seems nobody has bothered thus far. You have to admit that sounds pretty painful.
I also wish I had AI in college. I would have used it to descramble the unintelligible utterances of the calculus lecturers who had minimal or no English language skills.
Those poor calculus lecturers are most likely required to teach in order to earn their PHD. It is unfortunate that most students do not get to learn higher level math because of it. I was the type of student who did better when the professor was difficult, but engaging.
For example, I hated English growing up and then I had a college English course with a professor who was absolutely passionate about it and made it fun. Now, I hate English a little less and could appreciate it more. We need more people like that for other subjects.
For the last two decades, YouTube (or better, MIT's OpenCourseWare) has provided instruction that sets a baseline.
I'm positive that college lecturers fall below this baseline, but there's plenty of alternatives that a moderately motivated student could use.
Part of the problem is that the typical ~20 year old student has little idea how to learn something and little opinion about what their education should produce, to guide them.
As someone who did well in Calculus and had engaging instructors I’m not sure I’d call any of the textbooks well written. That being said I doubt AI’s ability to be enlightening to any student tackling PDEs or vector calculus
Google contributed the code, and the entire concept, of DWARF fission to both GCC and LLVM. This suggests that rather than overlooking something obvious that they'll be embarrassed to learn on HN, they were aware of the issues and were using the solutions before you'd even heard of them.
There's no contradiction, no missing link in the facts of the story. They have a huge program, it is 2GiB minus epsilon of .text, and a much larger amount of DWARF stuff. The article is about how to use different code models to potentially go beyond 2GiB of text, and the size of the DWARF sections is irrelevant trivia.
> They have a huge program, it is 2GiB minus epsilon of .text,
but the article says 25+GiB including debug symbols, in a single binary?
also, I appreciate your enthusiasm in assuming that because some people do something in an organization, it is applied consistently everywhere. Hell, if it were microsoft other departments would try to shoot down the "debug tooling optimization" dpt
yes and that's what I'm saying, I find it crazy to not split the debug info out. At least on my machine it really makes a noticeable difference of load time if I load a binary which is ~2GB with debug info in or the same binary which is ~100MB with debug info out.
Doesn't make any difference in practice. The debug info is never mapped into memory by the loader. This only matters if you want to store the two separate i.e lazy load debug symbols if needed.
ELF is just a container format and you can put literally anything into one of its sections. Whether the DWARF sections are in "the binary" or in another named file is really quite beside the point.
Google is made of many thousands of individuals. Some experts will be aware of all those, some won't. In my team, many didn't know about those details as they were handled by other builds teams for specific products or entire domains at once.
But since each product in some different domains had to actively enable those optimizations for themselves, they were occasionally forgotten, and I found a few in the app I worked for (but not directly on).
ICF seems like a good one to keep in the box of flags people don't know about because like everything in life it's a tradeoff and keeping that one problematic artifact under 2GiB is pretty much the only non-debatable use case for it.
reply