Signal Radar

2026-10-26

Tech news with the retellings removed: first-party announcements, measured numbers, and things you can use today.

242papers read
→
23shortlisted
→
5must-read

163 s · 216,600 input tokens · ≈ $0.0091 · jev-1.13.0 via typesafe

Must-read ≥ 90%

98%measurementreddit-ai

RTX 3080 20GB got reBAR and P2P unlock! +70% prompt processing speed

/u/No-Refrigerator-1672

Measured result 98%
Abstract

P2P is finally unlocked for RTX 3080 20GB - this leads to massive performance improvements in tensor parallel mode prompt processing speed. First, i want to acknowledge that this tremendous achievement belongs to u/nathannguyennng - he can't post to r/locallama due to karma requirements, and gave me permission to post it instead. Please follow his original post for installation instructions, and give it an upvote! Here, I'm sharing my tests results. Test system: Proxmox Virtual Environment 9.2.21, linux kernel 6.14.11-9-pve, nvidia driver 615.71.09 Hardware: Threadripper 1920x on x399 Zenith extreme motherboard GPUs: dual RTX 3080 20GB, both installed into PCIe 3.0 x16 slots, limited to 240W power test environment: vllm 0.32.0 with cyankiwi/Swift-1.5-Qwen3.8-27B-AWQ-INT4 , MTP enabled, FP8 KV cache, tensor parallel, full launch command: vllm serve cyankiwi/Swift-1.5-Qwen3.8-27B-AWQ-INT4 --max-num-seqs 4 --enable-auto-tool-choice --tool-call-parser qwen3_coder --reasoning-parser qwen3 --tensor-parallel-size 2 --enable-prefix-caching --kv-cache-memory-bytes 6G --kv-cache-dtype fp8_e4m3 --enable-prompt-tokens-details --speculative-config '{"method":"qwen3_next_mtp","num_speculative_tokens":3}' --enable-chunked-prefill --attention-backend FLASHINFER --default-chat-template-kwargs '{"reasoning_effort": "medium"}' Both GPUs are limited to 240W of power. I have tested 3 configurations: 1) completely stock; 2) gpu-unlock ; 3) gpu-unlock + ReBAR + P2P Single stream prefill (prompt processing) speed was measured as prompt_length / time_to_first_token. In both cases, gain is defined as percentage increase over stock configuration. Prompt Tokens TTFT stock ms TTFT gpu_unlock ms TTFT gpu_unlock+p2p ms Prefill stock tok/s Prefill gpu_unlock tok/s Gain Prefill gpu_unlock+p2p tok/s Gain 8192 8471.2 7012.7 3938.5 967.1 1168.2 21% 2080 115% 16384 17572.5 14417.8 8283.4 932.4 1136.4 22% 1978 112% 32768 36753.8 29970 18179.3 891.6 1093.4 23% 1802.5 102% 65536 79432 64173.5 41010.9 825.1 1021.2 24% 1598 94% 131072 183593.1 146010 100237.2 713.9 897.7 26% 1307.6 83% 261900 465890.2 362192.5 272345.5 562.1 723.1 29% 961.6 71% As you can see, enabling both gpu_unlock and P2P gains you massive prompt processing improvement, anywhere between 70% and 115%. P2P alone gives up to 70% improvement over gpu_unlock. Measuring decode (token generation) when MTP enabled is tricky, because tok/s output metric relies heavy on MTP acceptance rate, which always changes. Therefore, instead of tok/s output rate, I measure inter-token latency (ITL) - this is time passed between two batches of tokens generated by inference engine. With MTP3, each batch contains anywhere between 1 and 4 tokens; so you token output rate is 1x to 4x the step rate I report. Prompt Tokens ITL Stock ms ITL gpu_unlock ms ITL gpu_unlock+p2p ms Decode stock step/s Decode gpu_unlock step/s Gain Decode gpu_unlock+p2p step/s Gain 8192 64.8057 62.5193 62.5695 15.43074 15.99506 4% 15.98223 4% 16384 62.9359 63.873 59.8 15.88918 15.65607 -1% 16.72241 5% 32768 60.2028 62.016 62.6955 16.61052 16.12487 -3% 15.95011 -4% 65536 66.0282 61.425 64.8648 15.14504 16.28002 7% 15.41668 2% 131072 62.5518 64.4644 60.561 15.98675 15.51244 -3% 16.51228 3% 261900 66.7368 60.26 60.3504 14.98424 16.59476 11% 16.5699 11% As real-life MTP acceptance length for agentic coding is floating around 2, 15 steps/s decode rate corresponds to 45 tok/s generation. I'm sorry if this sounds confusing, but this is the only way for you can isolate variations in MTP acceptance during tests and extract raw performance numbers. As you can see, decode results are all over the place, but within noise, except 261k long prompt test; in which stabl;e measurable performance is delivered by gpu_unlock, not p2p. Verdict: in tensor parallel mode, both recent unlocks for 3080 20GB give unimaginably large prompt processing speedup, but basically no improvement for token generation. So, if you're running long prompt tasks (that includes agentic coding too), you should check out those prompts. Also, expect far lesser improvements on systems that don't have full PCIe connectivity to the second gpu. Again, I want to express my massive thanks to u/nathannguyennng , author of ReBAR and P2P unlock - what a day for 3080 owners! submitted by /u/No-Refrigerator-1672 to r/LocalLLaMA [link] [comments]

rss:fe48fa9ebcac836bUseful?👍👎
97%measurementreddit-ai

CUDA: fuse FFN gate/up matmuls and GLU in MMQ with interleaved gate/up rows by anujj · Pull Request #29948 · ggml-org/llama.cpp

/u/jacek2023 · discussion

Measured result 97%Usable today 42%
Abstract

time to download some speedup DGX Spark (GB10), llama-bench -ngl 999 -fa on -p 16384 -n 0 -b 2048 -ub 2048 -ctk f16 -ctv f16 -r 5 , tok/s: model type master PR Qwen3.8-27B Q4_K_M 840.1 899.9 +7.1% Q5_K_M 840.1 880.6 +4.8% Q6_K 751.2 785.8 +4.6% Q8_0 876.2 940.1 +7.3% IQ4_XS 882.4 948.0 +7.4% Qwen3.6-27B Q4_K_M 816.6 865.6 +6.0% Q5_K_M 800.0 851.1 +6.4% Q6_K 720.8 770.4 +6.9% Q8_0 876.9 940.2 +7.2% IQ4_XS 882.2 948.5 +7.5% Llama-3.1-8B Q4_K_M 2749.3 3000.6 +9.1% Q5_K_M 2699.4 2960.3 +9.7% Q6_K 2392.2 2616.0 +9.4% IQ4_XS 2933.9 3249.0 +10.7% RTX 5090, llama-bench -ngl 999 -fa on -p 16384 -n 0 -b 2048 -ub 2048 -ctk f16 -ctv f16 -r 5 , tok/s: model type master PR Qwen3.8-27B Q4_K_M 3688.4 3790.9 +2.8% Q5_K_M 3589.5 3659.6 +2.0% Q6_K 3220.5 3281.0 +1.9% Q8_0 3617.3 3766.9 +4.1% IQ4_XS 3796.2 3926.8 +3.4% Qwen3.6-27B Q4_K_M 3567.9 3660.3 +2.6% Q5_K_M 3429.8 3525.3 +2.8% Q6_K 3105.2 3187.8 +2.7% Q8_0 3628.7 3788.4 +4.4% IQ4_XS 3785.6 3915.4 +3.4% Llama-3.1-8B Q4_K_M 12071.5 12625.9 +4.6% Q5_K_M 11823.0 12297.3 +4.0% Q6_K 10513.1 10928.6 +4.0% IQ4_XS 12997.6 13603.3 +4.7% submitted by /u/jacek2023 to r/LocalLLaMA [link] [comments]

rss:90931809f49e65eeUseful?👍👎
97%measurementreddit-releases

Opus 5.5 writes slop code, but succeeds anyways. A research project inspired by SlopCodeBench

/u/aj_marshall

Measured result 97%
Abstract

A few months ago, I ran across this paper proposing a benchmark called SlopCodeBench. The idea is that you give an agent a problem split into a bunch of checkpoints, and at each one it has to add a new feature on top of its own old code without breaking anything. Along the way the benchmark measures how "sloppy" the code gets, using two metrics: structural erosion (how much complexity piles up in a few giant branchy functions) and verbosity (how much of the code is redundant). The paper found that agent code gets messier the longer the agent works on it, and that agents get worse at keeping everything passing as they go. The obvious takeaway is that the agent is digging its own grave. Messy code is hard to extend, so it fails. I wasn't convinced that held for agents, so I tested it. I ran Opus 5.5 through all 196 checkpoints ($266 in API costs, ouch) and checked whether messier code predicted worse results. Short version: - Its code did get messier, just like the paper says. Erosion and verbosity both went up in 22 of 35 problems. - Messiness didn't predict whether it got the next checkpoint right, once you compare checkpoints within the same problem. - It almost never broke old stuff. Only about 0.3% of previously passing tests regressed, and messier repos didn't regress any more often. - Messy code didn't make the next change more expensive. Code size did, though: every time a codebase doubled, the next checkpoint cost about 19% more. - Across the whole leaderboard, models that write cleaner code don't solve more problems. The correlation is basically zero. Also, the headline 17% strict solve rate undersells Opus pretty badly. On the tests for each new spec, it passed 84-92%. Big caveats: this is one run of one model on fairly small programs, and the comparisons are observational. A small effect could still be hiding in there. But if it exists, it's nowhere near the penalty these metrics are supposed to be warning us about. Full video link here submitted by /u/aj_marshall to r/ClaudeAI [link] [comments]

rss:c2b736123fc0f091Useful?👍👎
94%releasereddit-ai

Nanbeige4.3-33B Quantised GGUF

/u/gladkos · discussion

Measured result 94%Usable today 85%
Abstract

Quant ladder of Nanbeige's new 33B model from 35.2GB down to 13.7GB For 32GB hardware the sweet spot is 20.3GB AD-IQ4_XS with a top-1% of 92.0% compared to BF16 submitted by /u/gladkos to r/LocalLLaMA [link] [comments]

rss:5d85f2298772b31bUseful?👍👎
94%releasereleases-ollama

ollama v0.40.11

github-actions[bot]

First-party 94%Usable today 87%
Abstract

Speech Ollama can now generate speech on macOS. ollama run plays text or a chat model's reply aloud as the audio is generated, and apps can stream audio through the OpenAI-compatible /v1/audio/speech endpoint. ollama run phonon " Hello from Ollama. " d3 decision models d3 brings vLLM Semantic Router's decision models to Ollama. Give a model text, structured state, or an image, and ask it to classify, answer yes or no, or score options with probabilities. The family includes 2B, 4B, 9B, and 27B sizes. ollama run d3 " A customer says their card was charged twice. " --ask " Is this a billing issue? " New Contributors @SynapShift made their first contribution in #19173 Full Changelog : v0.40.10...v0.40.11

Same story elsewhere (1)
rss:0eb36f31626f0592Useful?👍👎

Maybe 80% to 90%

88%releasehn

fheroes2: A recreation of Heroes of Might and Magic II game engine

tosh

Usable today 88%
Abstract

Article URL: https://github.com/ihhub/fheroes2 Comments URL: https://news.ycombinator.com/item?id=50230384 Points: 205 # Comments: 71

rss:5468909c98fc071cUseful?👍👎
88%announcementhn

Cerebras Deploys Trillion-Parameter AI Models

gmays

First-party 88%
Abstract

Article URL: https://www.cerebras.ai/blog/how-we-deploy-trillion-parameter-frontier-models-on-cerebras Comments URL: https://news.ycombinator.com/item?id=50227356 Points: 355 # Comments: 132

rss:fc7ea0ec44f47576Useful?👍👎
88%releasereleases-llama-cpp

llama.cpp b11886

github-actions[bot]

First-party 88%Usable today 86%
Abstract

qwen: merge tensors on convert ( #31028 ) qwen: merge tensors on convert convert: use generator functions qwen4exp: remove conts and pre-scale Website: https://llama.app Attestations: https://github.com/ggml-org/llama.cpp/attestations/59667111 macOS/iOS: macOS Apple Silicon (arm64) macOS Apple Silicon (arm64, KleidiAI enabled) DISABLED macOS Intel (x64) iOS XCFramework Linux: Ubuntu x64 (CPU) Ubuntu arm64 (CPU) Ubuntu s390x (CPU) Ubuntu x64 (Vulkan) Ubuntu arm64 (Vulkan) Ubuntu x64 (CUDA 12) - CUDA 12.8 libraries Ubuntu x64 (CUDA 13) - CUDA 13.4 libraries Ubuntu arm64 (CUDA 13) - CUDA 13.4 libraries Ubuntu x64 (ROCm 10.0) Ubuntu x64 (OpenVINO) Ubuntu x64 (SYCL FP32) Ubuntu x64 (SYCL FP16) Linux arm64 (Snapdragon: CPU, Adreno GPU, Hexagon NPU) - setup guide Android: Android arm64 (CPU) Android arm64 (Snapdragon: CPU, Adreno GPU, Hexagon NPU) - setup guide Windows: Windows x64 (CPU) Windows arm64 (CPU) Windows arm64 (OpenCL Adreno) Windows x64 (CUDA 12) - CUDA 12.4 DLLs Windows x64 (CUDA 13) - CUDA 13.4 DLLs Windows arm64 (CUDA 13) - CUDA 13.4 DLLs Windows x64 (Vulkan) Windows arm64 (Vulkan) Windows x64 (OpenVINO) Windows x64 (SYCL) Windows x64 (ROCm 10.0) openEuler: DISABLED openEuler x86 (310p) openEuler x86 (910b, ACL Graph) openEuler aarch64 (310p) openEuler aarch64 (910b, ACL Graph) UI: UI

rss:29169a8cdeda9d7bUseful?👍👎
87%releasereleases-llama-cpp

llama.cpp b11882

github-actions[bot]

First-party 87%Usable today 83%
Abstract

grammar: limit recursion depth to prevent stack overflow ( #29495 ) ( #29755 ) Website: https://llama.app Attestations: https://github.com/ggml-org/llama.cpp/attestations/59655793 macOS/iOS: macOS Apple Silicon (arm64) macOS Apple Silicon (arm64, KleidiAI enabled) DISABLED macOS Intel (x64) iOS XCFramework Linux: Ubuntu x64 (CPU) Ubuntu arm64 (CPU) Ubuntu s390x (CPU) Ubuntu x64 (Vulkan) Ubuntu arm64 (Vulkan) Ubuntu x64 (CUDA 12) - CUDA 12.8 libraries Ubuntu x64 (CUDA 13) - CUDA 13.4 libraries Ubuntu arm64 (CUDA 13) - CUDA 13.4 libraries Ubuntu x64 (ROCm 10.0) Ubuntu x64 (OpenVINO) Ubuntu x64 (SYCL FP32) Ubuntu x64 (SYCL FP16) Linux arm64 (Snapdragon: CPU, Adreno GPU, Hexagon NPU) - setup guide Android: Android arm64 (CPU) Android arm64 (Snapdragon: CPU, Adreno GPU, Hexagon NPU) - setup guide Windows: Windows x64 (CPU) Windows arm64 (CPU) Windows arm64 (OpenCL Adreno) Windows x64 (CUDA 12) - CUDA 12.4 DLLs Windows x64 (CUDA 13) - CUDA 13.4 DLLs Windows arm64 (CUDA 13) - CUDA 13.4 DLLs Windows x64 (Vulkan) Windows arm64 (Vulkan) Windows x64 (OpenVINO) Windows x64 (SYCL) Windows x64 (ROCm 10.0) openEuler: DISABLED openEuler x86 (310p) openEuler x86 (910b, ACL Graph) openEuler aarch64 (310p) openEuler aarch64 (910b, ACL Graph) UI: UI

rss:f5067271fe9e2b72Useful?👍👎
86%businessreddit-tech

Nvidia discusses $2,000-per-GPU annual software fee for running agents on AI infrastructure — firm already charges more than twice that amount for its AI Enterprise software platform

/u/Logical_Welder3467 · discussion

Measured result 86%First-party 41%
Abstract

submitted by /u/Logical_Welder3467 to r/technology [link] [comments]

rss:6fd8469ae45013fcUseful?👍👎
86%businessbluesky367 likes · 101 reposts · 17 replies

Accenture Tells Employees They Can Now Spend Only $29 on Claude Per Month

404 Media · @404media.co, 404media.co · discussion

Measured result 86%
Abstract

companies to employees a few months ago: you better use AI companies now: wait, wait, just $29 a month on claude pls www.404media.co/accenture-te... Linked page: Some employees who spend as much as $1,000 on Claude usage each month are scrambling to find ways to maintain access to the tool.

Same story elsewhere (1)
bsky:7a9ef59f70bd8f49Useful?👍👎
86%opiniontechmeme

Amazon Bee Frontier review: a simple $75 AI wearable that excels at always-on listening, summarizing conversations, and suggesting follow-up actions (M.G. Siegler/Spyglass)

Measured result 86%Usable today 59%
Abstract

M.G. Siegler / Spyglass : Amazon Bee Frontier review: a simple $75 AI wearable that excels at always-on listening, summarizing conversations, and suggesting follow-up actions — Amazon's quiet, listening AI wearable is also pretty killer? — I'm not sure people really understand what is coming with AI and wearables.

rss:fb8663f2506b5840Useful?👍👎
84%incidentreddit-tech

Launched in October 2026 at $1,999, Apple’s foldable faces inner display cracks and dust ingress reports across multiple markets

/u/efap1701 · discussion

Measured result 84%Usable today 66%
Abstract

submitted by /u/efap1701 to r/technology [link] [comments]

rss:734941ca1c60e29eUseful?👍👎
83%releasereleases-llama-cpp

llama.cpp b11883

github-actions[bot]

Usable today 83%First-party 79%
Abstract

llama-quant : fix 4D tensor quantization using ggml_nrows() and name-based expert detection ( #30820 ) llama-quant : fix quantizing 4D tensors nrows_total was ne[1]*ne[2], so for a 4D tensor only the first ne[2] slices were quantized and the rest of the rows were dropped. Use ggml_nrows(tensor) to count all rows, including ne[3]. Fixes #29916 llama-quant : detect expert tensors by name and fix imatrix size for 4D tensors The MXFP4_MOE path used ne[2] > 1 to detect MoE expert tensors. This is wrong for non-expert tensors with 3 or more dims, e.g. MLA projections (BailingMoE3) and 4D conv kernels. Use the tensor name instead: all tensors used by GGML_OP_MUL_MAT_ID are named *_exps or *_chexps. This also removes the BailingMoE3 special case. The imatrix holds one vector of ne[0] values per 2D slice, so the expected size is ne[0]*ne[2]*ne[3], not ne[0]*ne[2]. This matches how the imatrix is indexed per row for 4D tensors in llama_tensor_quantize_impl. Assisted-by: Claude Opus 5.5 Website: https://llama.app Attestations: https://github.com/ggml-org/llama.cpp/attestations/59658790 macOS/iOS: macOS Apple Silicon (arm64) macOS Apple Silicon (arm64, KleidiAI enabled) DISABLED macOS Intel (x64) iOS XCFramework Linux: Ubuntu x64 (CPU) Ubuntu arm64 (CPU) Ubuntu s390x (CPU) Ubuntu x64 (Vulkan) Ubuntu arm64 (Vulkan) Ubuntu x64 (CUDA 12) - CUDA 12.8 libraries Ubuntu x64 (CUDA 13) - CUDA 13.4 libraries Ubuntu arm64 (CUDA 13) - CUDA 13.4 libraries Ubuntu x64 (ROCm 10.0) Ubuntu x64 (OpenVINO) Ubuntu x64 (SYCL FP32) Ubuntu x64 (SYCL FP16) Linux arm64 (Snapdragon: CPU, Adreno GPU, Hexagon NPU) - setup guide Android: Android arm64 (CPU) Android arm64 (Snapdragon: CPU, Adreno GPU, Hexagon NPU) - setup guide Windows: Windows x64 (CPU) Windows arm64 (CPU) Windows arm64 (OpenCL Adreno) Windows x64 (CUDA 12) - CUDA 12.4 DLLs Windows x64 (CUDA 13) - CUDA 13.4 DLLs Windows arm64 (CUDA 13) - CUDA 13.4 DLLs Windows x64 (Vulkan) Windows arm64 (Vulkan) Windows x64 (OpenVINO) Windows x64 (SYCL) Windows x64 (ROCm 10.0) openEuler: DISABLED openEuler x86 (310p) openEuler x86 (910b, ACL Graph) openEuler aarch64 (310p) openEuler aarch64 (910b, ACL Graph) UI: UI

rss:525177d5e1efc60fUseful?👍👎
82%releasereddit-releases

Introducing Clown Prophecy (The only actually fix to degredation)

/u/roychodraws

Usable today 82%
Abstract

Clown Context Suite: chain MiniMax H3 clips without them slowly turning to mush If you’ve chained H3 clips, you know the problem. Every new clip starts from the tail of the last one, and each time a little detail gets lost. That loss stacks up, so by clip 10 everything looks soft and washed out. The reason is that we only ever tell the model where to start . We never tell it where to end . It’s like telling an archer roughly which way to aim but never giving them a target. They can be the best archer in the world and they still won’t hit the spot you wanted. So I gave it a target. There are three pieces: 🎈 Clown Context takes the last frames of the previous clip and pins them to the start of the new one, so the motion carries over smoothly. 🔮 Clown Prophecy is the time travel part. Before a shot is rendered, it renders just the ending of that shot as a short, fresh clip, straight from the shot’s prompt and reference pictures. Because it’s made from scratch and not from a tired old tail, it’s full quality. It’s basically a picture of how the shot is supposed to end, from a video that doesn’t exist yet. 🤡 Clown Anchoring takes that ending and pins it to the back of the shot. Now the shot has a good start from the last clip and a clean target at the end, and the model has to fill in the middle and land on good-quality frames. Every time you do that, the quality gets pulled back up. Run Prophecy every couple of shots and the degradation never gets bad enough to notice. Other stuff in the pack: Bypass switch and “run every N shots” , so you can drop it into any workflow and only use Prophecy when you want it. Clown Shot Counter can count your saved clips by itself, so batches just work. An example workflow is included. GitHub: https://github.com/roycho87/clown_context_suite big thanks to u/shutupyourewrong for helping me brainstorm this. I wouldn't have gotten to this point without bouncing ideas off him. Also for giving me the name. Also, believe it or not I have to give some credit to foxydits. He claimed the secret to stopping degradation was to put an end frame reference image which.... was completely wrong... but it did spark the idea that helped me come up with this. In honor of his contribution I've changed the name of my workflow. submitted by /u/roychodraws to r/StableDiffusion [link] [comments]

rss:bcd6ad17a35120e6Useful?👍👎
82%announcementreddit-tech

Just finished my multiplayer system in C and turns out we can support 50k players in a single server at 60hz simulation tick

/u/dechichi · discussion

Measured result 82%
Abstract

submitted by /u/dechichi to r/programming [link] [comments]

rss:c8b09bd5c4754874Useful?👍👎
82%releasereleases-llama-cpp

llama.cpp b11888

github-actions[bot]

Usable today 82%First-party 77%
Abstract

common, grammar: add recursive depth limit, make it a requirement ( #31153 ) common, grammar: add recursive depth limit, make it a requirement catch more recursive functions common : tidy up peg parser changes grammar : reject candidates in a loop, without a depth limit The depth limit in llama_grammar_reject_candidates_for_stack counted the code points of a vocab token, so any token of 256 chars or more was always rejected under a grammar, such as the 512-space token of GLM-4.7-Flash or the long space tokens of Laguna-S-2.1. The rejection now walks the code points with its own stack of levels instead of recursing: there is no limit and no stack risk, whatever the length of a token from the GGUF, and the masks match master. grammar : track rejected candidates as indices into the input At a given code point a candidate only differs from its input by the position of its code point pointer, so the levels now carry indices into the input candidates instead of copies. The first level needs no special case and the rejects map back to the input directly. Grammar sampling gets faster than master on GLM-4.7, Laguna, Qwen3.6 and gemma-4 with the json, list and spaces grammars, same masks. nit : shorten the comment of llama_grammar_reject_step common : add depth_guard for schema walks grammar : move GRAMMAR_RECURSIVE_LIMIT into the .cpp common : reduce recursion limit for peg parser improve Co-authored-by: Alde Rojas hello@alde.dev Co-authored-by: Pascal admin@serveurperso.com Website: https://llama.app Attestations: https://github.com/ggml-org/llama.cpp/attestations/59723426 macOS/iOS: macOS Apple Silicon (arm64) macOS Apple Silicon (arm64, KleidiAI enabled) DISABLED macOS Intel (x64) iOS XCFramework Linux: Ubuntu x64 (CPU) Ubuntu arm64 (CPU) Ubuntu s390x (CPU) Ubuntu x64 (Vulkan) Ubuntu arm64 (Vulkan) Ubuntu x64 (CUDA 12) - CUDA 12.8 libraries Ubuntu x64 (CUDA 13) - CUDA 13.4 libraries Ubuntu arm64 (CUDA 13) - CUDA 13.4 libraries Ubuntu x64 (ROCm 10.0) Ubuntu x64 (OpenVINO) Ubuntu x64 (SYCL FP32) Ubuntu x64 (SYCL FP16) Linux arm64 (Snapdragon: CPU, Adreno GPU, Hexagon NPU) - setup guide Android: Android arm64 (CPU) Android arm64 (Snapdragon: CPU, Adreno GPU, Hexagon NPU) - setup guide Windows: Windows x64 (CPU) Windows arm64 (CPU) Windows arm64 (OpenCL Adreno) Windows x64 (CUDA 12) - CUDA 12.4 DLLs Windows x64 (CUDA 13) - CUDA 13.4 DLLs Windows arm64 (CUDA 13) - CUDA 13.4 DLLs Windows x64 (Vulkan) Windows arm64 (Vulkan) Windows x64 (OpenVINO) Windows x64 (SYCL) Windows x64 (ROCm 10.0) openEuler: DISABLED openEuler x86 (310p) openEuler x86 (910b, ACL Graph) openEuler aarch64 (310p) openEuler aarch64 (910b, ACL Graph) UI: UI

rss:8907bfb4526c8daaUseful?👍👎
82%releasereleases-llama-cpp

llama.cpp b11884

github-actions[bot]

First-party 82%Usable today 81%
Abstract

llama: fix exhausting CPU and MEM caused by dry sequence breaker ( #31035 ) Website: https://llama.app Attestations: https://github.com/ggml-org/llama.cpp/attestations/59663486 macOS/iOS: macOS Apple Silicon (arm64) macOS Apple Silicon (arm64, KleidiAI enabled) DISABLED macOS Intel (x64) iOS XCFramework Linux: Ubuntu x64 (CPU) Ubuntu arm64 (CPU) Ubuntu s390x (CPU) Ubuntu x64 (Vulkan) Ubuntu arm64 (Vulkan) Ubuntu x64 (CUDA 12) - CUDA 12.8 libraries Ubuntu x64 (CUDA 13) - CUDA 13.4 libraries Ubuntu arm64 (CUDA 13) - CUDA 13.4 libraries Ubuntu x64 (ROCm 10.0) Ubuntu x64 (OpenVINO) Ubuntu x64 (SYCL FP32) Ubuntu x64 (SYCL FP16) Linux arm64 (Snapdragon: CPU, Adreno GPU, Hexagon NPU) - setup guide Android: Android arm64 (CPU) Android arm64 (Snapdragon: CPU, Adreno GPU, Hexagon NPU) - setup guide Windows: Windows x64 (CPU) Windows arm64 (CPU) Windows arm64 (OpenCL Adreno) Windows x64 (CUDA 12) - CUDA 12.4 DLLs Windows x64 (CUDA 13) - CUDA 13.4 DLLs Windows arm64 (CUDA 13) - CUDA 13.4 DLLs Windows x64 (Vulkan) Windows arm64 (Vulkan) Windows x64 (OpenVINO) Windows x64 (SYCL) Windows x64 (ROCm 10.0) openEuler: DISABLED openEuler x86 (310p) openEuler x86 (910b, ACL Graph) openEuler aarch64 (310p) openEuler aarch64 (910b, ACL Graph) UI: UI

rss:9932b2dbb6b1d1a7Useful?👍👎
80%releasereddit-releases

Flight Simulator 95/98 finally running on 64-bit Windows, patched by Claude Code

/u/Torturephile

Usable today 80%
Abstract

Howdy there. I'm a lifelong fan of Flight Simulator who doesn't let go of old stuff. Since I've seen people using Claude Code to come up with some crazy mods that mash two entirely unrelated games together without somehow breaking, I figured I'd give Claude Code two old games, FS95 and FS98 , which don't run on 64-bit Windows, to figure out why they won't. Something much simpler, right? I knew for about ten years that both games crash out of divide by zero exceptions that occur with their handling of their 2D and 3D windows, so I suspected that the issue had to do with two of both games' DLLs, namely WINDOW.DLL and G3D.DLL. I tried running both games with DxWnd with the "handle exceptions" box ticked, but the games were unplayable with extremely glitchy rendering. A Reddit user named u/rozniak wrote some interesting stuff about it years ago. Anyway, I got Claude to patch the aforementioned DLLs for FS95 and it worked, but once I was debugging FS98 , it discovered that it was the game's EXE file that was the culprit, not the DLLs. It used its finding to trace down the same issue in FS95 's EXE so its original DLLs could be left alone. Here's what Claude stated: "FLTSIM98.EXE contains the game's routine Microsoft wrote to handle these faulting divisions. When a division fails, it reads the instruction from memory, puts a capped result in the right registers, and skips past the instruction. The game runs everything under it with __try / __except , which is exactly the mechanism 64-bit Windows can’t reach inside a window callback. Windows has a second kind of exception handler, the vectored handler, which runs before that callback boundary matters. The game’s routine has exactly the signature such a handler needs. So the patch adds 86 bytes at the program’s entry point that register the routine with AddVectoredExceptionHandler and then start the game normally. One patch covers every division with exactly the results the game was written for." To add to this, FS95 has its routine located on its DIVTRAP.DLL, not on its EXE like FS98 does. With that said, now both games run on 64-bit Windows with no issue based on my testing. Here's the MediaFire download of the EXE patcher, because I don't feel like supplying the EXEs myself. Alternatively, here's the GitHub link since someone requested it. You still need to install the games, either from your CDs or from the high seas. Read the readme file included for instructions, please. Also, please comment about any issues. Edit: the patch was redone so that it only handles the division faults, so if the game crashes for non-division faults, Windows will handle it. The assembly code is now included as well. Sorry mods for updating the text again. submitted by /u/Torturephile to r/ClaudeAI [link] [comments]

rss:babcf26484660552Useful?👍👎
80%analysistechmeme

iPhone Duo teardown: 5/10 repairability, a foldable record, but some screens crack along the fold, possibly because a hinge support bar fails to drop far enough (Elizabeth Chamberlain/iFixit News)

Measured result 80%Usable today 35%
Abstract

Elizabeth Chamberlain / iFixit News : iPhone Duo teardown: 5/10 repairability, a foldable record, but some screens crack along the fold, possibly because a hinge support bar fails to drop far enough — Apple's folding iPhone finally made it to our teardown table. Some owners' screens didn't make it through setup.

rss:8a1396efdf40a9e3Useful?👍👎
80%releasereleases-llama-cpp

llama.cpp b11889

github-actions[bot]

Usable today 80%First-party 57%
Abstract

cuda : use std::string instead of VLA for archName ( #30463 ) cuda : use std::string instead of VLA for archName Modernize the code (old C style) and fix the following warnings: ggml/src/ggml-cuda/ggml-cuda.cu:180:19: warning: variable length arrays in C++ are a Clang extension [-Wvla-cxx-extension] 180 | char archName[archLen + 1]; | ^~~~~~~~~~~ ggml/src/ggml-cuda/ggml-cuda.cu:180:19: note: read of non-const variable 'archLen' is not allowed in a constant expression ggml/src/ggml-cuda/ggml-cuda.cu:179:9: note: declared here 179 | int archLen = strlen(devName); | ^ Signed-off-by: Adrien Gallouët angt@huggingface.co Add a comment about archName Signed-off-by: Adrien Gallouët adrien@gallouet.fr Signed-off-by: Adrien Gallouët angt@huggingface.co Signed-off-by: Adrien Gallouët adrien@gallouet.fr Website: https://llama.app Attestations: https://github.com/ggml-org/llama.cpp/attestations/59725951 macOS/iOS: macOS Apple Silicon (arm64) macOS Apple Silicon (arm64, KleidiAI enabled) DISABLED macOS Intel (x64) iOS XCFramework Linux: Ubuntu x64 (CPU) Ubuntu arm64 (CPU) Ubuntu s390x (CPU) Ubuntu x64 (Vulkan) Ubuntu arm64 (Vulkan) Ubuntu x64 (CUDA 12) - CUDA 12.8 libraries Ubuntu x64 (CUDA 13) - CUDA 13.4 libraries Ubuntu arm64 (CUDA 13) - CUDA 13.4 libraries Ubuntu x64 (ROCm 10.0) Ubuntu x64 (OpenVINO) Ubuntu x64 (SYCL FP32) Ubuntu x64 (SYCL FP16) Linux arm64 (Snapdragon: CPU, Adreno GPU, Hexagon NPU) - setup guide Android: Android arm64 (CPU) Android arm64 (Snapdragon: CPU, Adreno GPU, Hexagon NPU) - setup guide Windows: Windows x64 (CPU) Windows arm64 (CPU) Windows arm64 (OpenCL Adreno) Windows x64 (CUDA 12) - CUDA 12.4 DLLs Windows x64 (CUDA 13) - CUDA 13.4 DLLs Windows arm64 (CUDA 13) - CUDA 13.4 DLLs Windows x64 (Vulkan) Windows arm64 (Vulkan) Windows x64 (OpenVINO) Windows x64 (SYCL) Windows x64 (ROCm 10.0) openEuler: DISABLED openEuler x86 (310p) openEuler x86 (910b, ACL Graph) openEuler aarch64 (310p) openEuler aarch64 (910b, ACL Graph) UI: UI

rss:8996c305c42a6f07Useful?👍👎
80%releasereleases-llama-cpp

llama.cpp b11880

github-actions[bot]

First-party 80%Usable today 78%
Abstract

tools : reject truncated GGUF tensor data in merge ( #31044 ) Co-authored-by: Shreya Agrawal shreyaagrawal@Shreyas-MacBook-Air.local Website: https://llama.app Attestations: https://github.com/ggml-org/llama.cpp/attestations/59649636 macOS/iOS: macOS Apple Silicon (arm64) macOS Apple Silicon (arm64, KleidiAI enabled) DISABLED macOS Intel (x64) iOS XCFramework Linux: Ubuntu x64 (CPU) Ubuntu arm64 (CPU) Ubuntu s390x (CPU) Ubuntu x64 (Vulkan) Ubuntu arm64 (Vulkan) Ubuntu x64 (CUDA 12) - CUDA 12.8 libraries Ubuntu x64 (CUDA 13) - CUDA 13.4 libraries Ubuntu arm64 (CUDA 13) - CUDA 13.4 libraries Ubuntu x64 (ROCm 10.0) Ubuntu x64 (OpenVINO) Ubuntu x64 (SYCL FP32) Ubuntu x64 (SYCL FP16) Linux arm64 (Snapdragon: CPU, Adreno GPU, Hexagon NPU) - setup guide Android: Android arm64 (CPU) Android arm64 (Snapdragon: CPU, Adreno GPU, Hexagon NPU) - setup guide Windows: Windows x64 (CPU) Windows arm64 (CPU) Windows arm64 (OpenCL Adreno) Windows x64 (CUDA 12) - CUDA 12.4 DLLs Windows x64 (CUDA 13) - CUDA 13.4 DLLs Windows arm64 (CUDA 13) - CUDA 13.4 DLLs Windows x64 (Vulkan) Windows arm64 (Vulkan) Windows x64 (OpenVINO) Windows x64 (SYCL) Windows x64 (ROCm 10.0) openEuler: DISABLED openEuler x86 (310p) openEuler x86 (910b, ACL Graph) openEuler aarch64 (310p) openEuler aarch64 (910b, ACL Graph) UI: UI

rss:c90e2e58b83ff6f6Useful?👍👎
80%releasereleases-llama-cpp

llama.cpp b11879

github-actions[bot]

Usable today 80%First-party 71%
Abstract

CUDA: fuse FFN gate/up matmuls and GLU in MMQ with interleaved gate/up rows ( #29948 ) cuda: fuse FFN gate/up and GLU in MMQ with interleaved gate/up rows For prompt processing, run the gate and up matmuls of a dense FFN as one mul_mat_q launch and apply the GLU in the write-back. The loaders take the gate weights as a second pointer and fill the weight tile with up and gate rows interleaved in chunks of 8, so each thread holds an up value and the matching gate value (rows r and r + 8 of an MMA tile). The MMA loop is unchanged: same tile, warp layout, vec_dot and one sum[] per thread. The fused write-back computes the GLU from registers and writes half the rows. The fused path uses the regular tiling (no stream-k) with the column tiles innermost so that neighbouring blocks share weight tiles. Enabled for Q4_K, Q5_K, Q6_K, Q8_0 and IQ4_XS on NVIDIA Turing and newer. cuda: assert the fused MMQ gate argument and trim redundant comments cuda: move the fused MMQ hint check to should_fuse and add TODOs cuda: pass prec_src1 to the fused MMQ write-back cuda: fuse only with efficient tiling and no fallback, merge the GLU write-back cuda: require has_fusion explicitly, drop the fusion-only src1 precision check cuda: launch the fused MMQ kernel through the stream-k kernel with one block per tile cuda: inline the MMQ tiling-efficiency check tests: one fused gate/up MMQ case per type and GLU op cuda: always launch the fused MMQ kernel with one block per tile tests: shorten the fused gate/up MMQ test comment cuda: select the fused MMQ loader and write-back in ggml_cuda_mmq_get_util_funcs cuda: run the fused MMQ kernel on the plain tiling path cuda: put the column tiles innermost in the MMQ plain tiling path Website: https://llama.app Attestations: https://github.com/ggml-org/llama.cpp/attestations/59646971 macOS/iOS: macOS Apple Silicon (arm64) macOS Apple Silicon (arm64, KleidiAI enabled) DISABLED macOS Intel (x64) iOS XCFramework Linux: Ubuntu x64 (CPU) Ubuntu arm64 (CPU) Ubuntu s390x (CPU) Ubuntu x64 (Vulkan) Ubuntu arm64 (Vulkan) Ubuntu x64 (CUDA 12) - CUDA 12.8 libraries Ubuntu x64 (CUDA 13) - CUDA 13.4 libraries Ubuntu arm64 (CUDA 13) - CUDA 13.4 libraries Ubuntu x64 (ROCm 10.0) Ubuntu x64 (OpenVINO) Ubuntu x64 (SYCL FP32) Ubuntu x64 (SYCL FP16) Linux arm64 (Snapdragon: CPU, Adreno GPU, Hexagon NPU) - setup guide Android: Android arm64 (CPU) Android arm64 (Snapdragon: CPU, Adreno GPU, Hexagon NPU) - setup guide Windows: Windows x64 (CPU) Windows arm64 (CPU) Windows arm64 (OpenCL Adreno) Windows x64 (CUDA 12) - CUDA 12.4 DLLs Windows x64 (CUDA 13) - CUDA 13.4 DLLs Windows arm64 (CUDA 13) - CUDA 13.4 DLLs Windows x64 (Vulkan) Windows arm64 (Vulkan) Windows x64 (OpenVINO) Windows x64 (SYCL) Windows x64 (ROCm 10.0) openEuler: DISABLED openEuler x86 (310p) openEuler x86 (910b, ACL Graph) openEuler aarch64 (310p) openEuler aarch64 (910b, ACL Graph) UI: UI

rss:4b033407bedc52bdUseful?👍👎
Near misses (10): just under your maybe bar, useful for tuning thresholds
Filtered by your exclusions (86)