jart is a genius. What they’ve done with Blink, Cosmopolitan C, Redbean, and now llama.cpp is incredible. It gives me hope for the future of systems/low-level programming.
Using mmap is basic systems programming knowledge and not "incredible" even though it's a useful contribution.
Using mmap to make LLaMA load faster
121–130 of 186 posts
Re: Using mmap to make LLaMA load faster
#122jart is a genius. What they’ve done with Blink, Cosmopolitan C, Redbean, and now llama.cpp is incredible. It gives me hope for the future of systems/low-level programming.
Using mmap is basic systems programming knowledge and not "incredible" even though it's a useful contribution.
The trick she did overriding malloc & friends to validate that the optimization would be worth doing is, in my mind, one of the high-points of the paper. It's a very clever way of making a meaningful measurement, which was the keystone of the entire change.
I've never heard of, thought of, or used that trick, and the fact she had it in her arsenal to apply to this very specific situation is pretty impressive, to me at least.
Re: Using mmap to make LLaMA load faster
#123Lol, there's a "broken" image in the footer that claims your IP for ipv4.games http://ipv4.games/user.html?name=jart
Re: Using mmap to make LLaMA load faster
#124Earlier quoted context omitted.
No? I mean yes, probably will get downvotes from the usual crowd. There is as a matter of fact some of that explicitly going on in the GitHub issue, which derailed the conversation. Such are the woes of being an internet micro celebrity I guess. Truly we live in the stupidest timeline.
> There is as a matter of fact some of that explicitly going on in the GitHub issue Could you link an example so I can learn/retract my comment? I didn't think there was actually going on.
Re: Using mmap to make LLaMA load faster
#125Re: Using mmap to make LLaMA load faster
#126Note that as a result of some llama drama associated with this change, @jart (author of this post) and @anzz1 are apparently no longer welcome as collaborators on llama.cpp: https://github.com/ggerganov/llama.cpp/pull/711#issuecomment...
I can't really understand what's going on after a few minutes poking around (best I can tell an argument over attribution?), but I certainly sympathize with the project author having to deal with some stupid internet drama that takes away from a cool project. This seems to be one of the less-discussed challenges with popular open-source.
Re: Using mmap to make LLaMA load faster
#127Earlier quoted context omitted.
I feel the same. I maybe should not be surprised, given that we live in the era of Unity and Electron, but using mmap() to load large files should be not be seen as rocket science. And this is basically available on almost any platform with a MMU and a kernel.
I think there just hasn't been a consumer application that is really resource constrained, for a long time now. Only things for enthusiasts have been. LLMs have product market fit, but running a useful one client side is resource constrained, but instead of it truly being a consumer hardware limitation, it just turns out they were never optimized to begin with - coming from the perceived "top AI/ML minds" at FAANGs,…
Re: Using mmap to make LLaMA load faster
#128> One of the downsides of the Linux cp command, is copying a file larger than RAM will destroy every existing entry in the file cache. Under normal circumstances this is a good thing, since a least recently used strategy usually works. However it can be problematic if you're just organizing your files on a production system where you don't want to disrupt performance. As far as I know, no standard command line utilit…
Re: Using mmap to make LLaMA load faster
#129There was a post a few months ago about a developer who's job it was to rework ML stuff into actual efficient code. This reminds me of that post because it seems that lots of ML stuff is just plain inefficient...in that they use way too many resources given the problem. And they're arguing about mmap, something that's been around forever. It reminds me of that speedup in a package manager because they were reading un…
This is just like any other technology. Use it wrong, you will get burned. Doesn't matter how shiny the container is.
"ML stuff" also (mostly?) includes purely statistical methods from the 90s that are deterministic and arguably the best way to solve a large variety of non-generative problems.
In fact, unless generation of arbitrary output is a major objective, it's likely you can solve whatever ML task on a workstation from 2010 that uses intel integrated graphics.
Re: Using mmap to make LLaMA load faster
#130Earlier quoted context omitted.
I don't get the "plagiarism/miscrediting" accusations. This was in the original PR ( https://github.com/ggerganov/llama.cpp/pull/613 ): > This PR was written in collaboration with @slaren. This PR is also rebased on PR #586 so please do not squash merge! Use either merge or rebase. jart made sure to that the other user got credit, in addition to making sure that their name was properly attributed in the commit log. G…
That's not the original PR. jart was working on a malloc() approach that didn't work and slaren wrote all the code actually doing mmap, which jart then rebased in a random new PR, changed to support an unnecessary version change, magic numbers, a conversion tool, and WIN32 support when that was already working in the draft PR. https://archive.ph/Uva8c This is the original PR: https://github.com/ggerganov/llama.cpp/pu…
This is BillG-style product skill -- there is a ton of work that goes into representing a piece of software as something important and valuable that people should buy into.