not original author but batching is one very important trick to make inference efficient, you can reasonably do tens to low hundreds in parallel (depending on model size and gpu size) with very little performance overhead
True! Devin Review doesn’t make the kind of judgements you mention, it just does its best to find bugs and help you understand the code faster. I managed to review a PR on an airplane (without starlink) with it earlier this week lol
I was scared to learn but then a coworker taught me the 4 commands I care about (jj new, jj undo, jj edit, jj log) and now I can't imagine going back to plain git.
Obviously the working tree should be a commit like any other! It just makes sense!
Codeium (now Windsurf) did this, and the plugins all still work with normal Windsurf login. The JetBrains plugin and maybe a few others are even still maintained! They get new models and bugfixes.
(I work at Windsurf but not really intended to be an ad I’m just yapping)
I think I remember one of the original ViT papers saying something about 2D embeddings on image patches not actually increasing performance on image recognition or segmentation, so it’s kind of interesting that it helps with text!
> We use standard learnable 1D position embeddings, since we have not observed significant performance gains from using more advanced 2D-aware position embeddings (Appendix D.4).
Although it looks like that was just ImageNet so maybe this isn't that surprising.
Yes! The retransmission logic in Linux NFS is independent of transport (see the `retrans` option in `mount.nfs`).
Weirdly enough this also means that if you’re running with TCP you can have retransmits at the NFS/SunRPC level and at the TCP level depending on your configuration.
Is there anything in particular you like about what Octant does? I don't see anything that actually looks at the object spec, just the status fields / etc.
I mean you can edit a big YAML file inside ArgoCD, but what I'm building is an actual web form (e.x. `spec.rules[].http.paths[].pathType` is a dropdown of `Prefix`, `ImplementationSpecific`, `Exact`), and all your documentation inline as you're editing.
People have tried this before but usually the UI version is not fully complete so you have to drop to YAML. Now that the spec is good enough it's possible to build a complete UI for this.
Having deployed a few of these over the last month or so, I feel like the devcontainer spec is very annoying. The alternative is what Coder does -- write some arbitrary terraform to bring up or down a workspace. I think this is better because I tend to need other things to go in a workspace (like an IAM role to access dev databases, associated Kubernetes resources, etc). With terraform I can configure whatever infrastructure I want to go along with workspaces.
The main downside I can see is that users have to write their workspaces for a particular deployment target. This would be a problem for e.x. open source projects trying to check in a workspace definition file of some kind. We standardize on Kubernetes across clouds and bare metal so it's not an issue for us, but it makes sense that it would be an issue for other use cases.
I think Chisel's main win is that it is great from an open-source research perspective.
Taking advantage of the functional nature of Chisel enables a set of generators called Chipyard [0] for things like cores, networking peripherals, neural network accelerators, etc. If you're focusing on exploring the design space of one particular accelerator and don't care too much about the rest of the chip, you can easily get a customized version of the RTL for the rest of your chip. Chisel handles connecting up all the components of the chip. All the research projects in the lab benefit from code changes to the generators.
Chisel even enables undergraduate students (like me!) to tape out a chip on a modern-ish process node in just a semester, letting Chisel significantly reduce the RTL we have to write. Most of the remaining time is spent working on the physical design process.
Architecture-wise, even a regular modern CPU isn't that hard. For example, Berkeley has the BOOMv3 core[0] which is performance-competitive[1] with commercial chips taped out in the last few years. I think commercial chips are faster because of improvements in analog design, and not some super special architecture sauce (although I'm sure there's some special sauce -- it's probably not the defining factor).
I would have assumed the win here would be that your Linux distribution or package manager on another OS can compile "VSCodium" themselves -- and you already trust them for all your other software, so this simplifies the trust chain somewhat.
In reality I think distributions that are willing to ship binaries (NixOS, Homebrew on MacOS) ship VSCodium, and other distributions (Alpine) have packages called things like `code-oss` that are basically the distribution's internal compiled version of VSCode and have nothing (?) to do with VSCodium.