Ali-Reza Adl-Tabatabai

Hey Satnam, didn't take you for a guitar music fan! I love the list so far. Here's a few to add: - Jeff Beck:“Plan B”. Jeff Beck can make his strat play notes no one else can. Also checkout his take on the Mingus classic "Goodbye Porkpie Hat". I love everything he's created. - Matteo Mancuso: “Drop D”. This guy will blow you away. He has a very unique technique. - Stevie Ray Vaughan: “Crossfire”. I just love the solo in this song. Almost like Jimi. - Vicente Amigo: “De Mi Corazón al Aire”. Flamenco at its finest. - Strunz & Farah: “Bola”. I'm a huge fan of this acoustic duo. The way they harmonize and blend styles, and their blazing solos is unique.

The three best guitar tracks ever. Fight me and tell me your top three, and please write one sentence about why that track is special to you. 1. Comfortably Numb, The Wall, Pink Floyd. For me, this is the Sanskrit of guitar solos. Gilmour totally smashed it. 2. How Soon is Now, The Smiths. Morrissey might be a total plonker, but Marr is an utter genius, a cool steady counterpoint to the pathetic self-absorbed navel-gazing whining of Morrissey. 3. Modern Music, De Bop Deluxe. If there ever was an unsung guitar hero, it is Bill Nelson. His guitar playing is utterly exquisite, and his lyrics give a voice to the words in my mind that I can't get out. A total genius.

Null pointer exceptions killing your developer productivity? Automatically modernize your Java codebase with Nullaway Auto Annotator! It unlocked massive gains in Developer productivity and code quality at Uber 🚀 Link in 🧵

Join us in exploring the nuances of PGO Optimization across Part 1 & Part 2 of our blog series. From theory to practice, we guide you through unlocking speed & efficiency in your apps. Begin the journey - Part 1: gitar.co/blog/unlocking… Part 2: gitar.co/blog/unlocking…

Tech debt due to stale feature flags makes code harder to maintain, test, and debug. Cleaning it up is always grunt work that's put off. At Gitar, we've built automation to take care of this. Reach out to find out mre.

Profile-guided optimizations (PGO) reduce capacity requirements and latency by 10-30% for Go, Rust, and other statically compiled languages in production. 🚀 All this without changing code. If this sounds too good to be true, its not. Processors waste significant time on front end stalls; i.e., I-cache and I-TLB misses, and branch mispredictions. These stalls are at the micro-architecture level, so you won't see them in your tools unless you look at hardware-level performance counters.

We’re also lucky to be supported by our exceptional investment partners at @Venrock who have strong conviction in our mission: @gan3sh and @ethanjb .

I’m fortunate to be joined by my awesome co-founders @rajbarik and @kageiit , and an exceptional founding team, @ask1604 , @sarinasays and Lazaro Clapp.

I’m now thrilled to announce that I’ve started on a new journey and launched a company, gitar.co 🚀 ! Our mission is to build the modern end-to-end development platform.

This picture is me going to work at Uber for the last time in September last year. After 6.5 amazing years, I left Uber to take some time off.

Some great work 👏 from @rajbarik on using Go Profile Guided Optimizations (PGO) for the #1BRC 🚀. Raj upstreamed the Go compiler changes for PGO to the Go codebase while he was at Uber. There's usually a 5-20% latency and cost reduction opportunity using PGO. At Uber, we got around 15% cost reduction in production on Go microservices, resulting in substantial cloud and capacity savings. 🙌 Statically compiled languages like Go, Rust, and C/C++ can't benefit as naturally from execution profiles as JIT-compiled languages like Java and JS can where a JIT compiler can guide its optimizations using profiles at runtime. Setting PGO up takes developer effort, both to set up initially and to run continuously...

@rajbarik This really nice work 👏. There is alot of potential in profile-guided optimizations for real workloads.

I recently investigated the 1brc challenge and its Go implementation, especially in the context of PGO (Profile-Guided Optimization) which we upstreamed to Google. However, I found that the benchmark is predominantly I/O-bound, limiting the potential benefits of advanced compiler techniques like PGO. However, there is still 3.59+% improvement via PGO. My analysis was conducted on a Mac OS with M2/64GB hardware. See details below: 1) Without PGO, average time per run = 8.08s 2) Profiling reveals that approximately 66% of the execution time is dedicated to I/O operations, specifically buffio.(*Scanner).Scan, indicating that it's an I/O-bound benchmark. Additionally, strconv.ParseFloat accounts for about 9% of the time, while accumulator::ensure contributes to 0.9% of the overall execution duration. 3) The Profile-Guided Optimization (PGO) we introduced in the Go compiler yields a 3.59% enhancement in this benchmark. This improvement is primarily due to the inlining of several critical functions across packages. Notably, when the inlining threshold was raised from 80 to 2000 for hot functions, both accumulator::ensure (100) and strconv.ParseFloat (1505) were effectively inlined, contributing to this performance boost. // benchstat pkg: github.com/warpstreamlabs… │ before.txt │     pgo_after.txt     │ │ sec/op │ sec/op  vs base       │ YourFunction-12 8.085 ± 2% 7.795 ± 1% -3.59% (p=0.000 n=10) 4) Another interesting finding is that by applying Profile-Guided Optimization (PGO) on slice sizes, currently manually set at 1<<5, we can entirely eliminate the accumulator::ensure function from the hotpath. Increasing the slice size to 1<<9 ensures that there's no need to call ensure for expanding slice sizes [and the copies], though this is contingent on using the same measurements.txt file from run-to-run. Similarly, PGO can be applied to optimally set the buffer size in bufio.NewReaderSize(sr, 1<<19). References: 1. 1brc challenge: x.com/gunnarmorling/… 2. Go implementation: github.com/warpstreamlabs… 3. Our PGO upstreamed proposal: go.googlesource.com/proposal/+/mas…

Here's the video to the "Developing at Uber Scale" keynote I gave at the Developer Productivity Engineering Summit last September. If you're curious about how we scaled 🚀 development at Uber, take a look at the video. youtube.com/watch?v=xCBlaT…

@kageiit @github Agreed

@github Git has been around for decades and there have been no fundamental advancements to rethink the developer experience from the ground up. It is time for some change!

Our SDKs are designed to empower you to build more robust, efficient, and creative solutions on top of the GitHub platform. Learn more about the dynamic, flexible, and user-friendly tools we're building using Kiota! github.blog/2024-01-03-our…

Amen.

@samswoora git is very powerful but too low-level. It needs a high-level abstraction is makes common tasks easy and intuitive.

Git is the worst tool that’s just good enough to work. Everyone who uses it has a trauma experience losing days of work from a bad command. Explaining git to a new engineer is the mental equivalent of nails on chalkboard. I’ve seen rly good engineers struggle with it

Ever wondered what's the best way to represent a range of numbers in code (e.g., 5, 6, ..., 25)? Should you use inclusive or exclusive lower and upper bounds? I ran into this gem (cs.utexas.edu/users/EWD/tran…) by Dijkstra written in 1982, linked from Rust's documentation on Regex matches. A great rationale for using a range with inclusive lower and exclusive upper bounds.

I've been writing a lot of code lately, mostly Rust. The memory safety guarantees, macros, and traits are great. I'm still learning and getting used to it, but at this point, I can't imagine going back to C++.

Profile-guided compiler optimizations (PGO) reduce capacity costs & latency by 15+%. Most companies writing Go & Rust services don't use PGO because its not a simple, automatic service: For statically-compiled languages, PGO requires integration with production profiling & CI/CD.

@kageiit We experienced this 1st-hand at Uber. Even though we favored buy over build, we invested significantly in configuring, integrating & scaling the tools we bought. Buy vs build in the developer tooling space is not so straightforward due to fragmentation, especially at scale.

Buy vs build for developer tools is broken. Businesses still need to have an internal developer platform team to integrate every point solution to solve the same problems like build times, test flakiness, developer analytics etc.

Nice Industry track FSE 2023 paper from Meta focused on eliminating dead codes due to stale feature flags and service endpoints: 2023.esec-fse.org/program/progra…