Collected from https://oldtamilpoetry.com/tag/thiruppavai/. Thiruppavai 01 மார்கழித் திங்கள் மதிநிறைந்த நன்னாளால் நீராடப் போதுவீர் போதுமினோ நேரிழையீர் சீர்மல்கும் ஆய்ப்பாடிச் செல்வச் சிறுமீர்காள் கூர்வேல் கொடுந்தொழிலன் நந்தகோ பன்குமரன் ஏரார்ந்த கண்ணி யசோதை இளம்சிங்கம் கார்மேனி செங்கண் கதிர்மதியம் போல்முகத்தான் நாரா யணனே நமக்கே பறை தருவான்

Off-CPU analysis is where the program behavior when it is not running is recorded and analysed. See Brendan Gregg's eBPF based off-CPU analysis: https://www.brendangregg.com/offcpuanalysis.html. While on-CPU performance monitoring tools such as perf give you an idea of where the program is actively spending its time, they won't tell you where the program is spending time blocked waiting for an action. Off-CPU analysis reveals information about where the program is spending time passively. Installation Install the tools from https://github.com/iovisor/bcc/. Enabling frame pointers The off-CPU stack trace collection, offcputime-bpfcc, requires the programs to be compiled with frame pointers for full backtraces. OCaml For OCaml, you'll need a compiler variant with frame pointers enabled. If you are installing a released compiler using opam, look for +fp variants in opam switch list-available.

Context Tarides has contributed significant amount of new code to OCaml with the Multicore OCaml project. While Tarides continues to develop and maintain this code, we have also gained significant expertise on several parts of the OCaml compiler. Not just on the code that we contributed. Recently, the OCaml compiler core team announced that they are facing a maintenance bottleneck. Given that our engineers have lots of expertise in many parts of the compiler, we encourage our engineers to spend up to 20% of their time with general OCaml maintenance. This can include reviewing PRs, triaging issues, improving documentation, etc. Below is a curated list of issues that we (KC, David, Jon, Jan) think Tarides has the expertise to work on. This list will be kept updated with reviewing ideas. If you pick one of these items, add your name to the item so that the work isn't duplicated. Some work does require multiple eyes, and use this note as a way to sync with others. Please report any OCaml maintenance work under the KR "Comp65: General maintenance of OCaml". If you want to propose to add an item, please ping one of us (KC, David, Jon, Jan) on #multicore-dev. This is just to ensure we can prioritise and only work on items that are relevant to the expertise in the teams. -- KC, David, Jon, Jan

Author: KC Sivaramakrishnan, CTO, Tarides OCaml recently won the ACM SIGPLAN PL Software award. The award recognizes a software system that has had significant impact on programming language implementation, research and tools. It is especially notable that 4 out of the 14 named OCaml compiler developers are affiliated with Tarides: Anil, David, Jérôme and me. In this post, I discuss the wider effort afoot at Tarides in order to make OCaml 5, the latest release of the OCaml programming language, succeed for the users. I should note that I shall specifically focus on the new OCaml 5 features and omit important developments such as Tarides' work on the OCaml platform, which is discussed elsewhere. I started hacking on OCaml when I joined Anil, Stephen and Leo (who are also named in the SIGPLAN PL software award) at OCaml Labs in the University of Cambridge in 2014 to work on the Multicore OCaml project. The aim of the Multicore OCaml project was to add native support for concurrency and parallelism to the OCaml programming language. Multicore OCaml compiler was maintained as a fork of the OCaml compiler for many years before it merged with the mainline OCaml compiler in January 2022. After almost an year of work stabilising the features, OCaml 5.0 was finally released in December 2022, nearly 8 years after the first commit. Has the Multicore OCaml project succeeded with the release of OCaml 5.0? The short answer is No. There is a long road to making OCaml 5 succeed for the users. The goal of making OCaml 5 succeed for the users is a two step process: Help users transition existing programs to OCaml 5 Help users take advantage of new concurrency and parallelism features in OCaml 5

TBD

This PR introduces a new configure-time flag --enable-tsan to enable compilation with ThreadSanitizer (TSan) instrumentation. This is a joint work with Fabrice Buoro (@fabbing), based on the work of Anmol Sahoo (@anmolsahoo25). We are also grateful to @jhjourdan and @maranget for their help on memory models and @gadmm and @art-w for useful feedback. TSan is an approach developed by Google to locate data races in code bases. It works by instrumenting your executables to keep a history of previous memory accesses (at a certain performance cost), in order to detect data races, even when they have no visible effect on the execution. TSan instrumentation has been implemented in various compilers (gcc, clang, as well as the Go and Swift compilers), and has proved very effective in detecting hundreds of concurrency bugs in large projects. Executables instrumented with TSan report data races without false positives. However, data races in code paths that are not visited will not be detected. Example A data race consists in two accesses to the same location, at least one of them being a write, without any order being enforced between them: type t = { mutable x : int }