# Optimisations Published articles for Optimisations. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Lazy Linearity for a Core Functional Language (POPL 2026) DevFeed: [Lazy Linearity for a Core Functional Language (POPL 2026)]() Original publisher: [Read original article]() Published: 2025-11-26T00:00:00Z Content type: article Language: en Sources: [Romes' Musings]() Topics: [Haskell](), [Compiler]() Tags: [compiler](), [evaluation](), [functional](), [haskell](), [language](), [optimisations](), [paper](), [types]() ### AI overview The article announces that the paper "Lazy Linearity for a Core Functional Language" will be published at POPL 2026. It explains a type system that captures linearity under Haskell's non-strict evaluation and is intended to support optimisations of linear Core programs. ### Source excerpt I'm very proud to announce that Lazy Linearity for a Core Functional Language, a paper by myself and Bernardo Toninho, will be published at POPL 26! [DOI, ACM]. The extended version of the paper, which includes all proofs, is available here [arXiv, PDF, DOI]. The short-ish story: In 2023, for my Master's thesis, I reached out to Arnaud Spiwack to discuss how Linear Types had been implemented in GHC. I wanted to research compiler optimisations made possible by linearity. Arnaud was quick to tell me: "Well yes, but you can't!" "Even though Haskell is linearly typed, Core isn't!"1 Linearity is ignored in Core because, as soon as it's optimised, previously valid linear programs become invalid. It turns out that traditional linear type systems are too syntactic, or strict, about understanding linearity - but Haskell, regardless of linear types, is lazily evaluated. Improving optimisations would have to wait. Our paper presents a system which, in contrast, also accepts programs that can only be understood as linear under non-strict evaluation. Including the vast majority of optimised linear Core programs (with proofs!). The key ideas of this paper were developed during my Master's, but it took a few more years of on-and-off work (supported by my employer Well-Typed) with Bernardo to crystalize the understanding of a "lazy linearity" and strengthen the theoretical results. Now, the proof of the pudding is in the eating. Go read it! Abstract Traditionally, in linearly typed languages, consuming a linear resource is synonymous with its syntactic occurrence in the program. However, under the lens of non-strict evaluation, linearity can be further understood semantically, where a syntactic occurrence of a resource does not necessarily entail using that resource when the program is executed. While this distinction has been largely unexplored, it turns out to be inescapable in Haskell's optimising compiler, which heavily rewrites the source program in ways that break syntactic l ## Python 3.14.0 (final) is here! DevFeed: [Python 3.14.0 (final) is here!]() Original publisher: [Read original article]() Author: Hugo van Kemenade Published: 2025-10-07T00:00:00Z Content type: release Language: en Sources: [Python Insider]() Topics: [Python 3.14](), [Python](), [releases](), [Compression](), [JIT](), [Command-line interface](), [Processes]() Tags: [command-line](), [compression](), [jit](), [macos](), [new-features](), [optimisations](), [performance](), [processes](), [python-3-13](), [python-3-14](), [release](), [releases](), [windows]() ### AI overview Python 3.14.0 is the stable release of Python's newest major version, introducing free-threaded support, deferred annotation evaluation, template string literals, multiple interpreters, Zstandard compression support, improved debugging and error messages, and other language and runtime changes. ### Source excerpt !Two snakes enjoying a pie with 3.14 on the top and π crimping Python 3.14.0 is now available python.org/downloads/release/python-3140/ This is the stable re... ## An Alternative Multi-Producer Approach DevFeed: [An Alternative Multi-Producer Approach]() Original publisher: [Read original article]() Author: Michael Barker (noreply@blogger.com) Published: 2013-12-15T19:42:00Z Content type: article Language: en Sources: [Bad Concurrency]() Topics: [Concurrency](), [Concurrent Programming](), [Code]() Tags: [cpu](), [messages](), [optimisations](), [performance](), [structure](), [threads]() ### AI overview The article explores an alternative multi-producer design for the Disruptor by using one ring buffer with a SingleProducerSequencer per producer and a custom event processor that polls multiple buffers. A throughput test with three producers and one consumer suggests the approach has merit, while the author notes unresolved sequence-value and wait-strategy design issues. ### Source excerpt Recently on InfoQ, Aliaksei Papou posted an article on some of his experiments with high performance interchange of messages between threads. There were a number of examples within the article, but I am going to focus on the multi-producer case. One of the optimisations that the article showed was that if you knew the number of producers that you have at initialisation time you can build a structure that significantly reduces contention. The existing MultiProducerSequencer does not have this constraint, which is essential for a large number of use cases. However, I wanted to see what we could achieve if I applied this approach to this Disruptor. Read more " ## Invoke Interface Optimisations DevFeed: [Invoke Interface Optimisations]() Original publisher: [Read original article]() Author: Martin Thompson (noreply@blogger.com) Published: 2012-04-29T10:22:00Z Content type: tutorial Language: en Sources: [Mechanical Sympathy]() Topics: [Java](), [Code](), [Compiler]() Tags: [code](), [inlining](), [intel](), [java](), [jvm](), [kernel](), [linux](), [optimisations](), [performance](), [processor]() ### AI overview This article explains how the HotSpot JVM dynamically inlines methods at runtime, including methods invoked through interfaces and overridden methods. It describes the relevant Java bytecode instructions and presents benchmark results from a Linux system using Oracle's Java 1.7.0_02 server JVM. ### Source excerpt I'm often asked about the performance differences between Java, C, and C++, and which is better. As with most things in life there is no black and white answer. A lot is often discussed about how managed runtime based languages offer less performance than their statically compiled compatriots. There are however a few tricks available to managed runtimes that can provide optimisation opportunities not available to statically optimised languages. One such optimisation available to the runtime is to dynamically inline a method at the call site. Many would say inlining is *the* major optimisation of dynamic languages. This is an approach whereby the function/method call overhead can be avoided and further optimisations enabled. Inlining can easily be done at compile, or run, time for static or private methods of a class because they cannot be overridden. It can also be done by Hotspot at run time which is way more interesting. In bytecode the runtime will see invokestatic and invokespecial opcodes for static and private methods respectively. Methods that involve late binding, such as interface implementations and method overriding, appear as the invokeinterface and invokevirtual opcodes respectively. At compile time it is not possible to determine how many implementations there will be for an interface, or how many classes will override a base method. The compiler can have some awareness but just how do you deal with dynamically loaded classes via Class.forName("x").newInstance()? The Hotspot runtime is very smart. It can track all classes as they are loaded and apply appropriate optimisations to give the best possible performance for our code. One such approach is dynamic inlining at the call site which we will explore. Code public interface Operation { int map(int value); } public class IncOperation implements Operation { public int map(final int value) { return value + 1; } } public class DecOperation implements Operation { public int map(final int value) { return va