Peter Holc

was at OpenAI hq yesterday and got to talk with their head of product about the new agentkit 🤯 a lot of people think this kills zapier (i even thought so at first). it doesn’t. agentkit is for devs, not no-coders. it’s about putting ai inside products, not automating workflows. this makes it easier for teams to build agents that live inside their own apps, not connect tools together. so yeah, this isn’t about replacing zapier. it’s about replacing ui. #ai #openai #chatgpt #agents #startups #developers

123

8 komentarzy

🔥 NUMA: The Hidden Latency Penalty in Multi-Socket Servers When we talk low-latency C++, we often obsess over branch predictors, inlining, or cache lines. But in multi-socket production servers, a bigger invisible cost lurks: NUMA (Non-Uniform Memory Access). 💡 What’s going on under the hood? • Each CPU socket has its own local memory. • Accessing memory on your own socket is fast. • Accessing memory on the other socket can be 2–3× slower, since it travels across the interconnect (Intel UPI, AMD Infinity Fabric, etc.). Now imagine a thread pinned to Socket 0, but allocating memory the OS placed on Socket 1’s NUMA node. 👉 Every access now pays a remote memory penalty — adding tens of nanoseconds per load. 👉 In a trading engine, that’s the difference between hitting the market first… or missing it entirely. ⸻ ✅ NUMA-Aware Best Practices: • Thread Affinity: Pin threads to cores deliberately. • NUMA-Aware Allocation: Use numactl, libnuma, or OS APIs to control where memory lives. • Partition Work: Keep data + compute on the same socket. • Socket Discipline: Some workloads isolate latency-critical tasks to a single socket to keep memory fully local. ⸻ 🔑 Key Takeaways • NUMA effects don’t show up on dev laptops — but they do on real multi-socket servers. • Cross-socket memory access can silently add tens of nanoseconds. • Profiling and locality awareness are essential to keep latency deterministic. 👉 Have you profiled your system for NUMA penalties? What’s your strategy — pinning, binding, or redesigning the workload? #Cplusplus #LowLatency #HFT #NUMA #PerformanceEngineering #SystemDesign #TradingSystems

68

2 komentarze

Most people use Firebase Performance Monitoring by default. But is it really the best option for Android & KMP apps? 🤔 In his latest video, Stefan Jovanovic puts it to the test using the Nutrisport KMP app. Stefan compares Firebase Performance Monitoring with the Kotzilla Platform and shows: - how Firebase works in practice for Android & KMP - where it falls short for multiplatform scenarios - how Kotzilla detects blocking calls, threading issues, and dependency slowdowns - just how easy it is to set up and get insights 👉 Watch the full video in the first comment If you’re building with Koin, Android, or Kotlin Multiplatform and care about real-world performance, this is worth your time. Kotzilla = performance monitoring made for modern Kotlin apps 🚀 Have fun! Miguel

67

1 komentarz

Interesting visual of a head-of-line blocking behavior in the Moderne CLI before and after a fix. Each block here represents a different repository with an #OpenRewrite recipe running on it in a large-scale multi-repository run. Knut Wannheden found the bug here yesterday and fixed. Concurrency is hard and the visuals here were produced by Claude Code looking at Moderne trace data we co-designed with our friends at American Express and introduced in 3.45.0. Next, we're exploring different prioritization methods where we're trying to balance between two apparently competing objectives: 1. Runs that should be fast are prioritized early to show incremental results as quickly as possible. After all, if a recipe result is incorrect on the first few repositories, developers like to cancel them quickly and iterate further on the recipe. 2. Runs on repositories that are going to take the longest shouldn't be prioritized last or we have the long tail effect on a run that you can observe even after the fix to the head-of-line blocking bug. We're thinking that Highest Response Ratio Next (HRRN) is a good balance between the two with a simple formula shown below. Over the years we've iterated on a "weight" measure for repositories based roughly on the density of information (including type attribution) of a repository present in the LST. Regardless of which method we wind up choosing, we'll be using this weight measure as one that run time is roughly proportional to. I know it may be a little outside of your typical problem space Geoffrey De Smet, but do you have any suggestions? I imagine our problem area is quite a bit simpler than yours typically. 😉

46

5 komentarzy