Those are multiple-choice questions. If some of them are "trick questions", where obvious answer (e.g. the value taken directly from question's text) is wrong, bad model might perform worse than a dice.
On the other hand, not sure where from 25% baseline for random answers come from. Since this is multiple-choice-out-of-4 test, random guessing should be correct in 1 in 15 cases, not 1 in 4.
It has the content three times (not including the title). Once in json (as escaped html) and twice in meta tags (as plain text). They used to have it in plain html too but that got hidden then removed.
Since that page is a little dense, the higher-level version: PCI supports Option ROMs (OpRoms) - plug in device like a NIC or a GPU, your BIOS actually loads compiled code from it and executes it on the CPU. In many systems for example PXE booting (net booting) is actually a function of the NIC, executing code on the CPU to load an operating system. We're talking actual x86/x86_64 machine code here running in the privileged pre-boot environment. Not portable or secure in any way. OpRoms _may_ now be checked for SecureBoot signatures on systems where that's set up properly at least.
EFI ByteCode (EBC) is meant to help at least the portability side. I'm not sure if anybody is actually delivering devices with EBC OpRoms yet though. I'm also not sure if anybody is looking at using the EBC VM to sandbox untrusted OpRoms.
"Yet"? The only card anyone's ever found that shipped with an EBC option ROM was from about 20 years ago, nobody's migrating to EBC and the general approach is to just emulate the x86 instructions instead. And secure boot has been verifying option ROMs since 2012.
Does this imply that plugging in a NIC into an ARM or PowerPC machine might fail to pxe boot if the manufacturer hasn’t prepped code for those platforms?
That's why there were separate "Mac editions" of certain cards (like GPUs) - the Option ROMs were different to support the Mac's frankensteined PPC OpenFirmware-like setup, and later to provide early EFI option roms when most x86-targeting cards were shipping with classic VBIOS.
EDIT: And while there was x86 emulator on many firmwares, it was often not enough to run everything, and x86 NIC firmware won't work for netbooting a PPC machine
Is there a way to use this (or similar) model in Visual Studio? Extensions on Visual Studio Marketplace are clunky and sluggish at best, if they even work at all.
> We’re open sourcing the model weights so the community can build fast, privacy-preserving autocomplete for every IDE - VSCode, Neovim, Emacs, and beyond.
Of course they are different products, but is there really a meaningful distinction between VS Code and an IDE? For all i care VS Code is a complete IDE.
> LoRa can reach a range of up to 3 miles (4.8 km) in urban areas, and up to 10 miles (16 km) in rural areas
In mountainous area LoRa on 868MHz band reaches over 100km. Last month we had a stratospheric balloon with a Meshtastic node attached. It established direct (albeit intermittent) connection between Warsaw and Berlin.
Hard limit is 3.5kbps with 148dB link budget (Medium Fast preset in Meshtastic [1]). In practice - a packet worth of hundred bytes every half a second or so.
Is that the cap of the whole system or can multiple users use it with individual caps of 3.5kbps? That's somehow both faster and slower than I expected.
If one node kept transmitting non-stop, it could push data out at 3.5kbps and no one else in that range can transmit at the same time.
However, in EU there is a legal limit of 1% duty cycle on 868MHz band and collision avoidance mechanism, meaning on average you can send a packet (up to 255 bytes) once a minute.
Not the person you asked, but I'm in a similar boat (15 years, polyglot but a lot of C#).
I mostly use VS Code to be honest. I use VSCode for other languages and for a long time it was the only graphical editor to have good remote development (over SSH) support.
Rider has that feature now though and is pretty nice too. I typically jump over to it when I need to profile something as it integrates with dotTrace. If you're coming from full-fat Visual Studio you'll probably prefer Rider.
Rider; however that's on a Windows work machine. We are a solid way to getting a linux/mac dev env going; maybe 30% is netstandard2.0, 10% is net9, the remainder net472 (including an old school non-sdk web app on IIS). Maybe ~ million LOC in its 14 year lifespan.
The context cache (or KV cache) is where intermediate results are stored. One for each output token. Its size depends on the model architecture and dimensions.
KV cache size = 2 * batch_size * context_len * num_key_value_heads * head_dim * num_layers * element_size. The "2" is for the two parts, key and value. Element size is the precision in bytes. This model uses grouped query attention, which reduces num_key_value_heads compared to a multi head attention (MHA) model.
With batch size 1 (for low-latency single-user inference), 32k context (recommended in the model card), fp16 precision:
2 * 1 * 32768 * 8 * 128 * 36 * 2 = 4.5GiB.
I think, anyway. It's hard to keep up with this stuff. :)
On the other hand, not sure where from 25% baseline for random answers come from. Since this is multiple-choice-out-of-4 test, random guessing should be correct in 1 in 15 cases, not 1 in 4.
reply