Implementing highly performant production systems requires the constant pursuit of speed – without compromising correctness. 🎯 HRT C++ developers achieve this by investigating compiler behavior and leveraging compiler optimisations. In the latest post on the #HRTBeat, London-based SWE Iwona Kotlarska explores compiler optimisations, virtual functions, noteworthy limitations, and how to write code that harnesses these techniques to maintain fast and accurate trading systems. Catch the full story here: https://lnkd.in/esWDpAay #Devirtualisation #CompilerOptimisation #CppProgramming
Hudson River Trading’s Post
More Relevant Posts
-
In this blog, CTO Zdenek Prikryl discusses the concept of, Re-targetable LLVM C/C++ compiler for RISC-V.
Re-targetable LLVM C/C++ compiler for RISC-V
https://codasip.com
-
Compiler Engineer @AMD | GSoC | LFX | LiFT | FSF | Element14 | SIH’19 Winner | LLVM BLR | Point Blank | SAE Aerodesign 3x🏅| NIOS AIR 4
"Premature optimization is the root of all evil" - Donald Knuth We’ve had a fantastic time organising our 10 part series on Common Compiler tools, and for our 10th and final talk in the series, it’s fitting that we talk about “Compiler Flags for Performance and Code Size”! Delivering this talk will be none other than one of the founders of LLVM Social Bangalore, Aditya Kumar. Aditya has been working as a Compiler Engineer for over a decade. He has been the organizer of the llvm workshop at the CGO conference, served as Program Chair of cppcon, and Program Chair of llvm developers conferences. The agenda of the talk, in his own words : “Modern optimizing compilers come with a large set of options that can affect performance as well as binary size of applications. While some compiler flags are well known (e.g., -O2, -O3) others remain a mystery to most software engineers. In this presentation I'll talk about compiler flags that can help improve performance and/or reduce binary size of applications. I'll also introduce popular tools to measure binary size and measure application performance. Finally I'll highlight common pitfalls with performance measurement techniques.” Date : 23rd September 2023 (Saturday) Time : 6:30 PM IST to 7:30 PM IST Mode : Online (MS - Teams) RSVP : https://lnkd.in/gB4w2tn6 Note : You must register to get the meeting link. CC : Pradeep Kumar (he/him) , Prerona Chaudhuri #LLVM #Compilers #Optimizations #OPT #Debugging #Code #Systems #Programming #LLVMBLR #Bangalore #LLVMSocial #GCC LLVM Foundation
Compiler Flags for Performance and Code Size | Common Compiler Tools #10, Sat, Sep 23, 2023, 6:30 PM | Meetup
meetup.com
-
Compiler Engineer @AMD | GSoC | LFX | LiFT | FSF | Element14 | SIH’19 Winner | LLVM BLR | Point Blank | SAE Aerodesign 3x🏅| NIOS AIR 4
LLVM is a collection of seemingly very different pieces of software, such as compiler backends, a post-link optimizer (BOLT), an implementation of parallel C++ Standard Library (pstl), a Polyhedral optimizer (Polly), a Multi-Level Intermediate Representation (MLIR) among many others. All these distinct pieces of technology are glued together into a single source of truth — the monorepo. But why? What do these projects share in common? How do changes in one project affect the other? What do all these projects even do? How can you leverage them together or as a part of a toolchain? To answer these questions - join us in this virtual meet-up where discuss and explain some of the sub-projects of LLVM, their functionality, usage, applications and more! This talk is #3 in our 10 part series, Introduction to Common Compiler Tools. Follow our YouTube Channel! : https://lnkd.in/gppdK2eT Title: Introduction to LLVM Project Tools Date: 5th August 2023 (Saturday) Time: 6:30pm - 7:30pm Mode: Online (MS-Teams) RSVP: https://lnkd.in/gnZc33E3 Note: Please RSVP for this talk to get the joining link. You must do this even if you’ve attended earlier talks. #LLVM #MLIR #libc #polly #openmp #clang #flang #lldb #compiler #code #systems #hpc #systemsoftware #cplusplus #pstl #STL #LLVMBangalore LLVM Foundation Pradeep Kumar (he/him) Prerona Chaudhuri Rahul Anand 💻 Radhakrishnan
Common Compiler Tools #3 | LLVM Project Tools | Online Only, Sat, Aug 5, 2023, 6:30 PM | Meetup
meetup.com
-
The Multi-Level Intermediate Representation Overview (MLIR) project is a novel approach to building reusable and extensible compiler infrastructure https://buff.ly/3YFOblC #developers #compilers #edu
MLIR
mlir.llvm.org
-
Testing the MSVC Compiler Backend https://lnkd.in/gZETtjs8 #cpp #cplusplus
Testing the MSVC Compiler Backend - C++ Team Blog
https://devblogs.microsoft.com/cppblog
-
How do you get the best SDK for a given RISC-V ISA? Let’s have a look in this blog as we focus on the C/C++ compiler, an essential part of the SDK. The compiler must, as much as possible, be able to automatically and wisely use also custom instructions. https://lnkd.in/dzqGBzbQ #riscv
Re-targetable LLVM C/C++ compiler for RISC-V
https://codasip.com
-
Embedded Software Engineer @ ACTIA Engineering Services | C/C++ & Python Developer | Embedded Linux
🚀 The purpose of the "inline" keyword in #embedded #C Inlining is a complier optimization technique where the compiler replaces a functioin call with the actual body of the function at the call site. This eliminates the overhead of function call and return, improving perfomance by reducing function call overhead and enabling better optimization opportunities. The "inline" keyword can server the following purposes : 🛎 Performance optimization : This can be particularly beneficial for small, frequently called functions where the cost of the function call becomes significant. 🛎 Code size optimization : In some cases, inlining function can result in increased code size due to code duplication. However, in certain embedded systems with limited memory resources, reducing function call overhead may take precedence over code size. 🛑 It's important to note that the use of the "inline" keyword is a hint to the compiler, and the compiler may choose to ignore the hint based on its own optimization heuristics. also the impact of inlining on performance and code size can vary depending on the specific architecture, optimization settings, and the chareteristics of the function being inlined.
-
If you add a static modifier for the unreachable function, the function will also be optimized out. Without the static keyword, the function might be externally called, so the compiler cannot optimize it and leave it in the asm code. (Then it causes the problem).
C++ compiler optimization can be wild sometimes. The code in this meme does indeed print "Hello World!", even though there is an infinite while loop in "main" and the function "unreachable" is never called in the program. So what is going on? According to the C++ standard, a thread is eventually assumed to do one of the following: 1. terminate 2. make a call to a library I/O function 3. access or modify a volatile object 4. perform a synchronization or an atomic operation If the compiler knows that a loop doesn't do any of these things, it can (and will) optimize it away when compiled with optimization flag (-O1). This is why the infinite while loop is being removed in the code below. Now since "main" doesn't have a return statement, the compiler puts the label of "unreachable" right below the label of "main" in the assembly. So the execution falls through to the "unreachable" function. Quite literally like a case in a switch statement without a break. I would love to hear your thoughts on this! :) --- Credit to the original poster of the meme: https://lnkd.in/gX8zs6a7
-
-
Runtime Environments in Compiler Design #snsinstitutions #snsdesignthinkers #designthinking A translation needs to relate the static source text of a program to the dynamic actions that must occur at runtime to implement the program. The program consists of names for procedures, identifiers, etc., that require mapping with the actual memory location at runtime. Runtime environment is a state of the target machine, which may include software libraries, environment variables, etc., to provide services to the processes running in the system. A procedure definition is a declaration that associates an identifier with a statement. The identifier is the procedure name, and the statement is the procedure body. For example, the following is the definition of procedure named readarray : procedure readarray; var i : integer; begin for i : = 1 to 9 do read(a[i]) end; When a procedure name appears within an executable statement, the procedure is said to be called at that point.
-
Use case of address sanitizer's and Time Travel Debugging (TTD) for C/C++.
We love hearing from people who use Time Travel Debugging (TTD) to dramatically reduce the time spent diagnosing issues. Our security team recently worked with the compiler team to solve a nasty deadlock when using ASAN and shared their journey. In the narrative below they make use of the reproducibility that trace files offer along with hardware breakpoints to solve the problem. If you already know how to debug with Windbg the barrier of entry to TTD is low. As a bonus tip, you can use the timeline view to construct call queries or memory queries instead of using breakpoints and stepping through execution. Or, you can use “dx -g” with a call or memory query to generate a table of information about the call parameters / memory values / etc (my favorite!) Do you have a good story to tell? Please share as inspiration for all of us! ----- When rolling ASAN out across Windows, we hit an interesting bug on a particular build target. Without ASAN the program worked as expected, however when we turned on ASAN we experienced a deadlock every time. I threw the program into TTD and the problem reproduced immediately. From the trace, I could see all threads were blocked on a lock. From there, I rewound the trace to the start, setting a breakpoint on the locking functions, conditional on my specific blocking lock, then executed forward. Very quickly I could see that one location locked the lock, but its epilog ended up calling unlock with a different point. Returning to the trace with the compiler team later, we were able to narrow down the issue to a specific place where, under ASAN combined with a tailcall, the stack would not be appropriately adjusted causing the saved registers to be clobbered. These clobbered registers then got fed into the unlock routine, leading to the inconsistent lock state and eventual deadlock. The fix for this issue is in VS 2022 17.10 Preview 3. Start to finish, from reproducing outside of the debugger to identifying the offending codegen took around four hours, with another hour spent later with the compiler team to identify the specific behavior that was at fault. Without a TTD trace, root causing this would have taken much, much longer. While I find TTD valuable in day-to-day debugging, especially in instances of toolchain issues, the time saved by the replayability is incredible.
Jülich Supercomputing Centre's Guest Student Programme incoming participant | CS @Durham University | Participant in IndySCC24 | Interested in High-Performance Computing (HPC) and low-latency C++ programming
3wThis is a great article! Although, it does make me wonder: If the impact of using virtual functions is quite significant (causing a whole heap of issues relating to cache efficiency) is it not better, at least for applications which require a lot of performance, to move away from the traditional OOP-heavy concepts altogether? This way, we can not only write more optimal structs to make use of cache locality, but also bypass v-pointers in general (and other issues commonly seen such as branch miss-prediction, compiled code size,…). Sure losing the flexibility of OOP is a downside, but the performance gains would potentially be massive. I would really be interested in hearing your opinions regarding this matter! Iwona K.