radarsat1

"boost research careers".. seems like a pretty drastic conclusion to draw based on a technology that has existed for like 3 years and only lately is any good..

I can sympathize, the Spanish naming system makes things legitimately complicated sometimes. My wife has a Spanish style name Firstname(s) Fathername Mothername. But very very often she just goes by Firstname Fathername but it's not technically her legal name and is confusing in the non Spanish world because people assume otherwise that Mothername is her last name.

So for our son we decided to try to skip any confusion by doing what you are alluding to, and making her Fathername into his middle name, and giving him just my last name, in the English style.

And it worked, sort of, but then we discovered it was absolutely not legal to do that in my wife's country of origin. So kind of hilariously his registration in that country is: Firstname Mothername Fathername Mothername.

They forced us to repeat the middle name as part of his last name too. Just ridiculous. I thought at the least they would allow us to reverse them, but no.

You're of course right but I can't help but point out one thing..

> but c'mon: tomatoes originated in the Americas!

Yes. But they were brought to Europe like right after Columbus landed and have been part of Italian and European cooking for longer than the US has existed. So you only sort of have a point here. (Same for corn, eg. polenta )

I mean, tomatoes are definitely a big part of Italian cuisine, despite any differences that American Italians introduced to the menu.

https://en.wikipedia.org/wiki/Columbian_exchange

> The primary goal of this is support for old/obscure hardware with no LLVM/GCC support.

If you're going to go to all this effort for an old target though, wouldn't the effort be better spent on making it an LLVM target? Then you'd get Rust and a bunch of other languages for free.

But maybe there are required parts of the LLVM IR that make this undesirable for certain targets, maybe requiring specific hardware features, I don't know. I guess also WASM-as-IR is a possible way to go. (Is that a thing?)

Edit: sorry I see that this point was already raised in this thread by ivanjermakov. Ignore.

is it strictly necessary to use different models or can you get similar results by doing the same thing but just using eg Codex in different agents & persona? curious if you've compared this

if you don't like the article that's fine, but it gets really tiring reading this kind of side-tracked comment thread in like.. every post.

people use LLMs for writing. we know! get over it.. or don't... i don't really care.. but I'd rather read a discussion about the article contents and not the writing style.

this kind of comment is the new "discuss the font choice / background color / anything but what the article is actually saying."

You can talk all you want about generalization and reasoning ability and AGI, but the fact is that it's also useful simply as a really user friendly database.

Even if it's only able to report facts from its dataset or perform simple synthesis of search results.

That it can actually reason to a certain extent is bonus points.

Not everything is about making money.

Also I don't get the impression the idea is intended for "most musicians".

> It's wildly better at tight and limited scope than large scale changes but even then I would rather code it myself.

One thing I would like to see is the use of LLMs for smarter semi-manual editing.

While programming I often need to make very similar changes in several places. If the instances are similar enough I can get away with recording a one-off keyboard macro to repeat, but if there are differences that are too difficult to handle this way I end up needing to do a lot of manual editing.

It would be nice to see LLMs tightly integrated into the editor so I can do a simple "place the cursor at things like this" based on an example or two. I'm sure more ideas for using LLMs more quickly perform semantic changes you intended are possible, instead of just prompting for a big diff. I feel there's a lot more innovation possible in this direction, where you're still "coding it yourself" but just faster.

Recently I got interested in how to "compile" a program definition into the weights of a Transformer. I settled for distilling the MLPs individually, but the attention weights are fully "calculated".

The example program [1] generates a Transformer that executes an RPN expression, using "breadcrumb" tokens to track its progress. The output looks like:

  Prompt: 3 4 + EXEC
  Output: c2 c1 c0 7
  
  Prompt: 3 4 + 3 3 + * EXEC
  Output: c2 c1 c0 7 c5 c4 c3 6 c6 c5 c2 42
  
  Prompt: 10 2 3 * + 2 + EXEC
  Output: c3 c2 c1 6 c4 c3 c0 16 c6 c5 c4 18

I think there's still a lot that could be improved but I wanted to document what I have done so far. It turned out very interesting and made me think about transformers, attention and particularly the structure of the residual stream in a new way.

[1]: https://github.com/radarsat1/rpn_transformer/blob/main/src/p...

you gave me the idea of using it to explore weird random scifi ideas, ended up spending way too much time clicking through details about the role of astrophage in the development of intelligence in deep sea life. Fun!

Wow, love this idea.

That was a fascinating read! Thanks for the link.

This reminds me a lot of the tricks to turn BERT into a generative model. I guess the causal masking that keeps it to essentially be autoregressive is an important difference though. Kind of best of both worlds.

Because the nature of transformers is that running a bunch of pregenerated tokens through them is a parallel operation, not autoregressive. That's how it works at training time, but speculative decoding uses it at inference time. So if you just want to check whether a set of known tokens is "likely" given the base model, you can run them all through and get probability distributions, no need to sample.

It's the same reason there's a difference in speed between "prompt processing" and "generation". The former is just taking the pre-generated prompt and building the KV cache, which is parallel, not autoregressive and therefore way faster.

Consider also that even reattaching nerves that are supposed to be there is not exactly a walk in the park. Look into finger reattachment surgery and post operation care. Think pain, tingling, a year or more of physiotherapy.. and that's in the best case that it actually works and you don't end up with a "dead" finger. Now, imagine that for your whole body.

> "Redefine" is a favorite word of AI. Honestly no need to read further.

You're not wrong, but it certainly is an annoying outcome of AI that we're not allowed to use.. words.. anymore.

> Should you be counting on confusion of an underpowered text-merge to catch such problems?

This does not really follow from my statement.

I said that underpowered text merge should not silently accept such situations, not that it is the only way to catch them. It doesn't replace knowing something about what you are merging, but it is certainly a good hint that something may be wrong or unexpected.

> Post-merge syntax checks are better for that purpose.

Better, yes, but I was addressing semantic issues, not syntactical. I have seen syntactically valid merges result in semantic inconsistency, it does happen.

I do agree with your last statement.. unit & integration tests, agent checks or whathaveyou, these all contribute to semantic checking, which is a good thing.

Can they be relied on here? Maybe? I guess the jury is still out. My testing philosophy is "you can only test for what you think of testing". And tests and agent checks have a signal to noise ratio, and are only as useful as their SNR allows.

There is no guaranteed way to stop bugs from happening, if there were it likely would have been discovered by now. All we can do is take a layered approach to provide opportunities for them to get caught early. Removing one of those layers (merge conflicts) is not clearly a good thing, imho, but who knows.. if agent checks can replace it, then sure, I'm all for it.

Is it a good thing to have merges that never fail? Often a merge failure indicates a semantic conflict, not just "two changes in the same place". You want to be aware of and forced to manually deal with such cases.

I assume the proposed system addresses it somehow but I don't see it in my quick read of this.

Something I want to add to the discussion is that the only time I've encountered this was not with a specific company but with an "AI recruitment agency", which I'm seeing getting more and more popular.

And while I get the idea of an agency handling hiring, what bothered me is that the terms of the AI interview were that it was relatively standardized for a given role, and that they would record it and put it on file to show to other companies, with the selling point being: do well in one interview and we'll shop your profile around for you!

Which is.. great if you do well I guess, but.. really unsettling if you don't. I mean, there was zero information that you'd be able to do it over, no advance details of the format, no practice session. So if you fail, or stammer, or get surprised by some detail of some question.. what, you're just "on file" now, out of reach for their entire client portfolio?

At least if you're doing it one company at a time, you mess up, then ok you move on and try again somewhere else. But the idea of making some random mistake (which happens all the time!) just blacklists you for some unknown number of companies, forever..

No way, that's too high stakes. I noped out.

> There are no details about training

my understanding was that they are not training at all, which would explain that. they are compiling an interpreter down to a VM that has the shape of a transformer.

ie they are calculating the transformer weights needed to execute the operations of the machine they are generating code for.

> Is it speed?

> Is it that you can backprop through this computation? Do you do so?

With respect, I feel that you may not have read the article.

> Because the execution trace is part of the forward pass, the whole process remains differentiable: we can even propagate gradients through the computation itself. That makes this fundamentally different from an external tool. It becomes a trainable computational substrate that can be integrated directly into a larger model.

and,

> By storing points across nested convex hulls, this yields a decoding cost of O(k+log⁡ n).

and,

> Regardless of their eventual capability ceiling, they already suggest a powerful systems primitive for speeding up larger models.

So yes, and yes.

> Where are the benchmarks?

Not clear what they should benchmark it against. They do compare speed to a normal KV Cache. As for performance.. if it's actually executing a Sudoku solver with a 100% success rate, it seems pretty trivial to find any model doing < 100% success rate. Sure, it would be nice to see the data here, agree with you there.

Personally I think it would be really interesting to see if this method can be combined with a normal model MoE-style. It is likely possible, the router module should pick up quite quickly that it predicts the right tokens for some subset of problems deterministically. I like the idea of embed all sorts of general solvers directly into the model, like a prolog solver for example. In fact it never would have occurred to me to just go straight for WASM, pretty interesting choice to directly embed a VM. But it makes me wonder what "smaller" interpreters could be useful in this context.

I'm curious if 1-bit params can be compared to 4- or 8-bit params. I imagine that 100B is equivalent to something like a 30B model? I guess only evals can say. Still, being able to run a 30B model at good speed on a CPU would be amazing.

it also reminds me a bit of this diffusion paper [1] which proposes having an encoding layer and a decoding layer but repeats the middle layers until a fixed point is reached. but really there is a whole field of "deep equilibrium models" that is similar. it wouldn't be surprising if large models develop similar circuits naturally when faced with enough data.

finding them on the other hand is not easy! as you've shown, i guess brute force is one way.. it would be nice to find a short cut but unfortunately as your diagrams show, the landscape isn't exactly smooth.

I would also hypothesize that different circuits likely exist for different "problems" and that these are messy and overlapping so the repeated layers that improve math for example may not line up with the repeated layers that improve poetry or whatever, meaning the basic layer repetition is too "simple" to be very general. that said you've obviously shown that there is some amount of generalizing at work, which is definitely interesting.

[1] https://arxiv.org/abs/2401.08741

This is interesting because I've been considering a similar project. I maintain a package for a scientific simulation codebase, it's all in Fortran and C++ with too much template code, which takes ages to build and is very error prone, and frankly a pain to maintain with its monstrous CMake spaghetti build system. Furthermore the whole thing would benefit with a rewrite around GPU-based execution, and generally a better separation between the API for specifying the simulation and the execution engine. So I've been thinking of rewriting it in Jax and did an initial experiment to port a few of the main classes to Python using Gemini. It did a fairly good job. I want to continue with it, but I'm also a bit hesitant because this is software that the upstream developers have been working on for 20+ years. The idea of just saying to them "hey look I rewrote this with AI and it's way better now" is not something I would do without giving myself pause for thought. In this case it's not about the license, they already use a permissive one, but just the general principle of suggesting a "replacement" for their work.. if I was doing it by hand it might be different, I don't know, they might appreciate that more, but I have no interest in spending that much time on it. Probably what I will do is just present the PoC and ask if they think it's worth attempting to auto-convert everything, they might be open to it. But yeah, the possibilities of auto-transpiling huge amounts of software for modernization purposes is a really interesting application of AI, amazing to think of all the possibilities. But I'm happy to have read the article because I certainly didn't think about the copyright implications.

I think your last point raises the following question: how would you change your answer if you know they read all about guns and death and how one causes the other? What if they'd seen pictures of guns? And pictures of victims of guns annotated as such? What if they'd seen videos of people being shot by guns?

I mean I sort of understand what you're trying to say but in fact a great deal of knowledge we get about the world we live in, we get second hand.

There are plenty of people who've never held a gun, or had a gun aimed at them, and.. granted, you could argue they probably wouldn't read that line the same way as people who have, but that doesn't mean that the average Joe who's never been around a gun can't enjoy media that features guns.

Same thing about lots of things. For instance it's not hard for me to think of animals I've never seen with my own eyes. A koala for instance. But I've seen pictures. I assume they exist. I can tell you something about their diet. Does that mean I'm no better than an LLM when it comes to koala knowledge? Probably!

> The hardest part was figuring out OpenLDAPs configuration syntax, especially the correct ldif incantations ..

As a long time Linux user on personal machines, I found myself for the first time a couple of years ago needing to support a small team and given them all login access to our small cluster. I figured, hey it's annoying to coordinate user ids over these machines, I should just set up OpenLDAP.. little did I know.. honestly I'm pretty handy at dealing with Linux but I was shocked to discover how complicated and annoying it was to set up and use OpenLDAP with NFS automounting home directories.

For the first time in my life I was like, "oh this is why people spend years studying system administration.."

I did get it working eventually but it was hard to trust it and the configuration GUI was not very good and I never fully got passwd working properly so I had to intervene to help people change their passwords.. in the end we ended up just using manually coordinated local accounts.

The whole time I'm just thinking, I must be missing something, it can't be this bad.. I'm still a bit flabbergasted by the experience.

> and the quality of the result can be measured automatically

this part is nontrivial though

I didn't say that 2.5gb is unreasonable for an LLM. I said it's an unreasonable payload size for a website. Not the same.

It sounds good, but I'm not sure that in practice sites will want to "let go" of control this way, knowing that some random model can be used. Usually sites with chatbots want a lot of control over the model behaviour, and spend a lot of time working on how it answers, be it through context control, guardrails or fine tuning and base model selection. Unless everyone standardizes on a single awesome model that everyone agrees is the best for everything, which I don't see happening any time soon, I think this idea is DOA.

Now I could imagine such an API allowing to request a model from huggingface for example, and caching it long term that way, yes just like LM Studio does. But doing this based on some external resource requesting it, vs you doing it purposefully, has major security implications, not to mention not really getting around the lead time problem you mention whenever a new model is requested.