<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://pinboard.in">
    <title>Pinboard (jm)</title>
    <link>https://pinboard.in/u:jm/public/</link>
    <description>recent bookmarks from jm</description>
    <items>
      <rdf:Seq>	<rdf:li rdf:resource="https://github.com/isene/glass"/>
	<rdf:li rdf:resource="https://www.hmpcabral.com/2026/04/26/the-fastest-linux-timestamps/"/>
	<rdf:li rdf:resource="https://xania.org/202512/07-division-again"/>
	<rdf:li rdf:resource="https://goperf.dev/"/>
	<rdf:li rdf:resource="https://byroot.github.io/ruby/performance/2025/03/04/the-pitchfork-story.html"/>
	<rdf:li rdf:resource="https://aws.amazon.com/blogs/database/timestamp-writes-for-write-hedging-in-amazon-dynamodb/?ck_subscriber_id=512829374"/>
	<rdf:li rdf:resource="https://www.quantamagazine.org/undergraduate-upends-a-40-year-old-data-science-conjecture-20250210/"/>
	<rdf:li rdf:resource="https://www.infoq.com/presentations/optimizing-java-app-kubernetes/"/>
	<rdf:li rdf:resource="https://pprof.me/"/>
	<rdf:li rdf:resource="https://github.com/orf/docker-repack"/>
	<rdf:li rdf:resource="https://dougallj.wordpress.com/2022/08/20/faster-zlib-deflate-decompression-on-the-apple-m1-and-x86/"/>
	<rdf:li rdf:resource="https://finbarrtimbers.substack.com/p/efficient-llm-inference"/>
	<rdf:li rdf:resource="https://finbarr.ca/how-is-llama-cpp-possible/?ref=openml.fyi"/>
	<rdf:li rdf:resource="https://jack-vanlightly.com/blog/2023/5/15/kafka-vs-redpanda-performance-do-the-claims-add-up"/>
	<rdf:li rdf:resource="https://shipilev.net/blog/2015/black-magic-method-dispatch/#_cheating_the_runtime_2"/>
	<rdf:li rdf:resource="https://twitter.com/nitsanw/status/1566677642748874753"/>
	<rdf:li rdf:resource="https://discord.com/blog/how-discord-supercharges-network-disks-for-extreme-low-latency"/>
	<rdf:li rdf:resource="https://dotat.at/@/2022-06-27-tolower-swar.html"/>
	<rdf:li rdf:resource="https://mazzo.li/posts/fast-pipes.html"/>
	<rdf:li rdf:resource="https://github.com/netty/netty/pull/10737/files"/>
	<rdf:li rdf:resource="https://github.com/WojciechMula/toys/tree/master/swar-utf8-length"/>
	<rdf:li rdf:resource="https://archive.md/ilW8S#selection-777.0-781.1"/>
	<rdf:li rdf:resource="https://pkolaczk.github.io/overhead-of-optional/"/>
	<rdf:li rdf:resource="https://dl.acm.org/doi/10.1145/3064176.3064187"/>
	<rdf:li rdf:resource="https://www.jeffgeerling.com/blog/2020/raspberry-pi-usb-boot-uasp-trim-and-performance"/>
	<rdf:li rdf:resource="https://blog.reverberate.org/2020/05/29/hoares-rebuttal-bubble-sorts-comeback.html"/>
	<rdf:li rdf:resource="https://www.infoq.com/news/2020/01/blake3-fast-crypto-hash/"/>
	<rdf:li rdf:resource="https://greenlab.di.uminho.pt/"/>
	<rdf:li rdf:resource="https://calendar.perfplanet.com/2019/eco-worriers-saving-the-planet-one-unoptimized-website-at-a-time/"/>
	<rdf:li rdf:resource="https://travisdowns.github.io/blog/2019/05/22/sorting.html"/>
	<rdf:li rdf:resource="http://pages.cs.wisc.edu/~jignesh/publ/Revenge_of_the_Interpolation_Search.pdf"/>
	<rdf:li rdf:resource="http://nullprogram.com/blog/2017/10/06/"/>
	<rdf:li rdf:resource="https://github.com/AdoptOpenJDK/jitwatch"/>
	<rdf:li rdf:resource="https://codahale.com/usl4j-and-you/"/>
	<rdf:li rdf:resource="http://lemire.me/blog/2016/06/30/fast-random-shuffling/"/>
	<rdf:li rdf:resource="https://twitter.com/akpurtell/status/698614296226312192"/>
	<rdf:li rdf:resource="http://bannalia.blogspot.fr/2015/06/cache-friendly-binary-search.html"/>
	<rdf:li rdf:resource="https://www.elastic.co/blog/frame-of-reference-and-roaring-bitmaps"/>
	<rdf:li rdf:resource="http://java-performance.info/hashmap-overview-jdk-fastutil-goldman-sachs-hppc-koloboke-trove-january-2015/"/>
	<rdf:li rdf:resource="http://vanillajava.blogspot.ie/2015/01/java-lambdas-and-low-latency.html"/>
	<rdf:li rdf:resource="http://blog.cloudera.com/blog/2015/05/working-with-apache-spark-or-how-i-learned-to-stop-worrying-and-love-the-shuffle/"/>
	<rdf:li rdf:resource="http://cglab.ca/~morin/misc/arraylayout/"/>
	<rdf:li rdf:resource="https://twitter.com/igrigorik/status/587446362880344064/photo/1"/>
	<rdf:li rdf:resource="https://thethemefoundry.com/blog/why-we-dont-use-a-cdn-spdy-ssl/"/>
	<rdf:li rdf:resource="https://github.com/plasma-umass/coz"/>
	<rdf:li rdf:resource="http://blog.cloudera.com/blog/2009/12/7-tips-for-improving-mapreduce-performance/"/>
	<rdf:li rdf:resource="https://github.com/facebook/folly/blob/master/folly/docs/FBVector.md"/>
	<rdf:li rdf:resource="https://github.com/cloudflare/lua-aho-corasick"/>
	<rdf:li rdf:resource="http://www.sciencemag.org/content/345/6199/862.short"/>
	<rdf:li rdf:resource="https://code.facebook.com/posts/816473015039157/making-facebook-s-software-infrastructure-more-energy-efficient-with-autoscale/"/>
	<rdf:li rdf:resource="http://cdn.oreillystatic.com/en/assets/1/event/44/TCP%20and%20the%20Lower%20Bound%20of%20Web%20Performance%20Presentation.pdf"/>
	<rdf:li rdf:resource="http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf"/>
	<rdf:li rdf:resource="http://shipilev.net/blog/2014/exceptional-performance/"/>
	<rdf:li rdf:resource="http://druid.io/blog/2014/02/18/hyperloglog-optimizations-for-real-world-systems.html"/>
	<rdf:li rdf:resource="http://engineering.linkedin.com/garbage-collection/garbage-collection-optimization-high-throughput-and-low-latency-java-applications"/>
	<rdf:li rdf:resource="http://normanmaurer.me/presentations/2014-facebook-eng-netty/slides.html"/>
	<rdf:li rdf:resource="https://github.com/netty/netty/commit/6efac6179e1e13e6caba2cec6109ce27862efc9a"/>
	<rdf:li rdf:resource="http://java-is-the-new-c.blogspot.ie/2013/07/impact-of-large-primitive-arrays-blobs.html"/>
	<rdf:li rdf:resource="https://twitter.com/jmason/status/423409032431271936"/>
	<rdf:li rdf:resource="https://plus.google.com/+IlyaGrigorik/posts/1sxencNkbNS"/>
	<rdf:li rdf:resource="http://www.slideshare.net/cpwatson/cpn302-yourlinuxamioptimizationandperformance"/>
	<rdf:li rdf:resource="http://stereopsis.com/radix.html"/>
	<rdf:li rdf:resource="http://mentablog.soliveirajr.com/2012/12/asynchronous-logging-versus-memory-mapped-files/"/>
	<rdf:li rdf:resource="http://psy-lob-saw.blogspot.ie/2013/10/spsc-revisited-part-iii-fastflow-sparse.html"/>
	<rdf:li rdf:resource="http://low-latency.com/article/groundbreaking-results-high-performance-trading-fpga-and-x86-technologies"/>
	<rdf:li rdf:resource="http://www.infoq.com/articles/tuning-tips-G1-GC"/>
	<rdf:li rdf:resource="http://edinburghhacklab.com/2013/09/probabalistic-scraping-of-plain-text-tables/"/>
	<rdf:li rdf:resource="http://www.infoq.com/articles/Java_Garbage_Collection_Distilled"/>
	<rdf:li rdf:resource="http://blog.aggregateknowledge.com/2011/12/12/big-memory-part-4/"/>
	<rdf:li rdf:resource="http://fastutil.di.unimi.it/"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://github.com/isene/glass">
    <title>isene/glass</title>
    <dc:date>2026-05-05T11:37:30+00:00</dc:date>
    <link>https://github.com/isene/glass</link>
    <dc:creator>jm</dc:creator><description><![CDATA[I love the purism of this -- "pure assembly terminal emulator. x86_64 Linux, no libc, X11 wire protocol".

<blockquote>Terminal emulator written in x86_64 Linux assembly. No libc, no runtime, pure syscalls. Speaks X11 wire protocol directly via Unix socket. Single static binary, ~155KB.  No toolkit, no rendering library, no external font engine. The TTF rasterizer (glyph) is embedded in-binary via %include. Just your keystrokes, the X11 server, and the kernel. Part of the CHasm (CHange to ASM) suite: bare (shell), show (file viewer), glass (terminal emulator).</blockquote>

]]></description>
<dc:subject>asm x86_64 assembly terminal hacks unix linux glass chasm optimization x11</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3a109b6e8b07/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:asm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:x86_64"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:assembly"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:terminal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:glass"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chasm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:x11"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.hmpcabral.com/2026/04/26/the-fastest-linux-timestamps/">
    <title>The fastest Linux timestamps</title>
    <dc:date>2026-04-27T11:42:47+00:00</dc:date>
    <link>https://www.hmpcabral.com/2026/04/26/the-fastest-linux-timestamps/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[lol -- "TL;DR: We can speed up timestamps on x86 Linux by 30% and maintain the same precision as the standard system clock by implementing our own timers without relying on vDSO. Almost nobody should do this"

This is good info, I had to implement fast timestamps a few years back in Java and this would have been useful.]]></description>
<dc:subject>time optimization performance linux libc speed clocks</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:cd189cceb922/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:time"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:libc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:speed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:clocks"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://xania.org/202512/07-division-again">
    <title>Multiplying our way out of division — Matt Godbolt’s blog</title>
    <dc:date>2025-12-08T10:59:48+00:00</dc:date>
    <link>https://xania.org/202512/07-division-again</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A very silly optimisation for the “binary to decimal” conversion problem:

<blockquote>The compiler has turned division by a constant ten into a multiply and a shift. There’s a magic constant 0xcccccccd and a shift right of 35! Shifting right by 35 is the same as dividing by 235 - what’s going on? [..]

What’s happening is that 0xcccccccd / 2**35 is very close to ⅒ (around 0.10000000000582077). By multiplying our input value by this constant first, then shifting right, we’re doing fixed-point multiplication by ⅒ - which is division by ten. The compiler knows that for all possible unsigned integer values, this trick will always give the right answer.</blockquote>

]]></description>
<dc:subject>hacks optimization bit-hacking binary decimal fixed-point arithmetric tricks</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7a0614b312f1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bit-hacking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:binary"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:decimal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fixed-point"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:arithmetric"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tricks"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://goperf.dev/">
    <title>Go Optimization Guide</title>
    <dc:date>2025-04-01T13:30:06+00:00</dc:date>
    <link>https://goperf.dev/</link>
    <dc:creator>jm</dc:creator><description><![CDATA["a collection of articles aimed at helping developers write faster, more efficient Go applications. Whether you're building high-throughput APIs, microservices, or distributed systems, this series offers practical patterns, real-world use cases, and low-level performance insights to guide your optimization efforts.

While Go doesn’t expose as many knobs for performance tuning as languages like C++ or Rust, it still provides plenty of opportunities to make your applications significantly faster. From memory reuse and allocation control to efficient networking and concurrency patterns, Go offers a pragmatic set of tools for writing high-performance code."]]></description>
<dc:subject>golang go reference optimization programming performance coding via:hn</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ffdb38949176/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:golang"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:go"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reference"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:hn"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://byroot.github.io/ruby/performance/2025/03/04/the-pitchfork-story.html">
    <title>Pitchfork</title>
    <dc:date>2025-03-21T10:30:41+00:00</dc:date>
    <link>https://byroot.github.io/ruby/performance/2025/03/04/the-pitchfork-story.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[An amazing journey through Ruby heap memory optimization, from one of the experts at Shopify, who are heavy users of Rails.  Using cleverly-timed fork(2) usage, it's possible to optimize memory usage in a Rails app and discard a lot of performance/heap overhead caused by lazy loading and poorly-timed in-memory caching.

This very much reminds me of optimising similar issues in Perl-land, back in the day -- and really helps me appreciate how easy the modern JVM world has it, in comparison.  There's a lot of complaints to be made about the complexity of optimising JVM garbage collection settings, but this kind of problem is malleable there without a fundamental architectural rewrite like this approach.]]></description>
<dc:subject>ruby performance optimisation optimization heap memory fork forking http services servers monolith rails gc</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2839524a8511/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimisation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:heap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fork"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:forking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:servers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monolith"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rails"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/blogs/database/timestamp-writes-for-write-hedging-in-amazon-dynamodb/?ck_subscriber_id=512829374">
    <title>write hedging in Amazon DynamoDB</title>
    <dc:date>2025-02-24T11:29:13+00:00</dc:date>
    <link>https://aws.amazon.com/blogs/database/timestamp-writes-for-write-hedging-in-amazon-dynamodb/?ck_subscriber_id=512829374</link>
    <dc:creator>jm</dc:creator><description><![CDATA["Write hedging" is a nice technique to address p99 tail latencies, by increasing the volume of writes (or in the case of read hedging, reads):

<blockquote>
Imagine you want a very low p99 read latency. One way to lower tail latencies is to hedge requests. You make a read request and then, if the response doesn’t come back quickly enough, make a second equivalent hedging request and let the two race. First response wins. If the first request suffered a dropped network packet, the second request will probably win. If things are just temporarily slow somewhere, the first request will probably win. Either way, hedging helps improve the p99 metrics, at the cost of some extra read requests.
</blockquote>

Write hedging has a little more complexity involved, since you want to avoid accidental overwrites during races; this blog post goes into some detail on a technique to do this in DynamoDB, using timestamps.  Good stuff.

(via Last Week In AWS)]]></description>
<dc:subject>via:lwia aws dynamodb write-hedging read-hedging p99 latencies tail-latencies optimization performance algorithms</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2c8e574b8330/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:lwia"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dynamodb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:write-hedging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:read-hedging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:p99"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latencies"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tail-latencies"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.quantamagazine.org/undergraduate-upends-a-40-year-old-data-science-conjecture-20250210/">
    <title>Undergraduate Upends a 40-Year-Old Data Science Conjecture</title>
    <dc:date>2025-02-11T14:21:54+00:00</dc:date>
    <link>https://www.quantamagazine.org/undergraduate-upends-a-40-year-old-data-science-conjecture-20250210/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is a great story; bonus that it's a notable improvement for the humble hash-table data structure:

<blockquote>Krapivin was not held back by the conventional wisdom for the simple reason that he was unaware of it. “I did this without knowing about Yao’s conjecture,” he said. His explorations with tiny pointers led to a new kind of hash table — one that did not rely on uniform probing. And for this new hash table, the time required for worst-case queries and insertions is proportional to (log x)^2 — far faster than x. This result directly contradicted Yao’s conjecture. Farach-Colton and Kuszmaul helped Krapivin show that (log x)^2 is the optimal, unbeatable bound for the popular class of hash tables Yao had written about.</blockquote>

Paper here -- https://arxiv.org/abs/2501.02305 .]]></description>
<dc:subject>data-structures hash-tables cs programming coding papers optimization open-addressing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:988d8723a281/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hash-tables"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:papers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:open-addressing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.infoq.com/presentations/optimizing-java-app-kubernetes/">
    <title>Optimizing Java Apps on Kubernetes</title>
    <dc:date>2025-01-23T14:45:35+00:00</dc:date>
    <link>https://www.infoq.com/presentations/optimizing-java-app-kubernetes/</link>
    <dc:creator>jm</dc:creator><description><![CDATA["Optimizing Java Applications on Kubernetes: beyond the Basics": Bruno Borges, at the InfoQ Dev Summit Boston, discusses the strategies for enhancing Java application performance on Kubernetes, focusing on leveraging JVM ergonomics, and managing garbage collection processes.  Some interesting tips here.]]></description>
<dc:subject>kubernetes java eks resources ops scaling scalability gc optimization jvm</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2c9522ab8d41/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kubernetes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:resources"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://pprof.me/">
    <title>pprof.me</title>
    <dc:date>2024-12-15T11:43:44+00:00</dc:date>
    <link>https://pprof.me/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[a web app to 'share and visualize .pprof profiles on an intuitive interface'.]]></description>
<dc:subject>pprof profiling optimization web tools coding</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:de5027a7391c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pprof"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:profiling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/orf/docker-repack">
    <title>docker-repack</title>
    <dc:date>2024-09-20T11:59:10+00:00</dc:date>
    <link>https://github.com/orf/docker-repack</link>
    <dc:creator>jm</dc:creator><description><![CDATA["This tool repacks a Docker image into a smaller, more efficient version that makes it significantly faster to pull. It does this by using a few different techniques such as removing redundant data and improving compression ratios."]]></description>
<dc:subject>docker containers optimization ops zstd</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:80a47ec77d03/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:zstd"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://dougallj.wordpress.com/2022/08/20/faster-zlib-deflate-decompression-on-the-apple-m1-and-x86/">
    <title>Faster zlib/DEFLATE decompression on the Apple M1 (and x86)</title>
    <dc:date>2024-09-13T12:08:48+00:00</dc:date>
    <link>https://dougallj.wordpress.com/2022/08/20/faster-zlib-deflate-decompression-on-the-apple-m1-and-x86/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Some decent low-level performance hacking on arm64/x86 (via Tony Finch)]]></description>
<dc:subject>via:fanf compression deflate optimization assembly c optimisation hacks</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e410c595df19/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:compression"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:deflate"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:assembly"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:c"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimisation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacks"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://finbarrtimbers.substack.com/p/efficient-llm-inference">
    <title>Efficient LLM inference</title>
    <dc:date>2023-10-20T11:04:37+00:00</dc:date>
    <link>https://finbarrtimbers.substack.com/p/efficient-llm-inference</link>
    <dc:creator>jm</dc:creator><description><![CDATA[More on distillation and quantization to reduce cost of LLMs]]></description>
<dc:subject>llms quantization distillation performance optimization ai ml</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:618a980bdedd/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:llms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:quantization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distillation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ml"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://finbarr.ca/how-is-llama-cpp-possible/?ref=openml.fyi">
    <title>How is LLaMa.cpp possible?</title>
    <dc:date>2023-10-20T11:03:07+00:00</dc:date>
    <link>https://finbarr.ca/how-is-llama-cpp-possible/?ref=openml.fyi</link>
    <dc:creator>jm</dc:creator><description><![CDATA["Recently, a project rewrote the LLaMa inference code in raw C++. With some optimizations and quantizing the weights, this allows running a LLM locally on a wild variety of hardware. If you are like me, you saw this and thought: What? How is this possible? Don’t large models require expensive GPUs? I took my confusion and dove into the math surrounding inference requirements to understand the constraints we’re dealing with." [...]

Summary: "Memory bandwidth is the limiting factor in almost everything to do with sampling from transformers. Anything that reduces the memory requirements for these models makes them much easier to serve -- like quantization! This is yet another reason why distillation, or just training smaller models for longer, is really important."

(via Luis Villa's https://www.openml.fyi/ , which is great!)]]></description>
<dc:subject>llama2 llms performance optimization c++ memory quantization via:luis-villa</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:23f5866ddb16/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:llama2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:llms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:c++"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:quantization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:luis-villa"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://jack-vanlightly.com/blog/2023/5/15/kafka-vs-redpanda-performance-do-the-claims-add-up">
    <title>Kafka vs Redpanda Performance</title>
    <dc:date>2023-05-15T16:19:55+00:00</dc:date>
    <link>https://jack-vanlightly.com/blog/2023/5/15/kafka-vs-redpanda-performance-do-the-claims-add-up</link>
    <dc:creator>jm</dc:creator><description><![CDATA[I don't use either service, but this is actually an excellent writeup of some high-end performance optimization on modern Linux EC2-based systems with NVMe SSDs, and the benchmarking of same]]></description>
<dc:subject>kafka redpanda benchmarks ec2 aws ssd optimization performance ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c155a58ab563/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:redpanda"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:benchmarks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ssd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://shipilev.net/blog/2015/black-magic-method-dispatch/#_cheating_the_runtime_2">
    <title>The Black Magic of (Java) Method Dispatch</title>
    <dc:date>2023-04-11T21:03:19+00:00</dc:date>
    <link>https://shipilev.net/blog/2015/black-magic-method-dispatch/#_cheating_the_runtime_2</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Some fascinating details of low-level Java performance optimization, particularly with JIT applied to OO method dispatch:

<blockquote>Programming languages like Java provide the facilities for subtyping/polymorphism as one of the ways to construct modular and reusable software. This language choice naturally comes at a price, since there is no hardware support for virtual calls, and therefore runtimes have to emulate this behavior. In many, many cases the performance of method dispatch is not important. Actually, in a vast majority of cases, the low-level performance concerns are not the real concerns.

However, there are cases when method dispatch performance is important, and there you need to understand how dispatch works, what runtimes optimize for you, and what you can do to cheat and/or emulate similar behavior in your code. For example, in the course of String Compression work, we were faced with the problem of selecting the coder for a given String. The obvious and highly maintainable approach of creating a Coder interface, a few implementations, and dispatching the virtual calls over it, had met some performance problems on the very tiny benchmarks. Therefore, we needed to contemplate something better. After a few experiments, this post was born as a reference for others who might try to do the same. This post also tangentially touches the inlining of virtual calls, as the natural thing during the optimization.</blockquote>

Discovered via this amazing commit: https://github.com/quarkusio/quarkus/commit/65dd4d43e2644db1c87726139280f9704140167c
]]></description>
<dc:subject>optimization performance java oo jit coding polymorphism</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:fcc32a99ea26/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:oo"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jit"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:polymorphism"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://twitter.com/nitsanw/status/1566677642748874753">
    <title>don't use JVM Flight Recorder profiling</title>
    <dc:date>2022-09-05T10:57:00+00:00</dc:date>
    <link>https://twitter.com/nitsanw/status/1566677642748874753</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Solid tip from Nitsan Wakart on Twitter:

<blockquote>If you are profiling for a CPU bottleneck [in java], DO NOT RELY ON JVM FLIGHT RECORDER METHOD PROFILING. Not even a little bit.

Use `async-profiler` for profiling(`-e cpu,lock,alloc`), with `--jfrsync default/profile` for extra JVM/JDK events.</blockquote>

]]></description>
<dc:subject>profiling java performance optimization jvm async-profiler via:twitter</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:acdfaf080f4b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:profiling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:async-profiler"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:twitter"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://discord.com/blog/how-discord-supercharges-network-disks-for-extreme-low-latency">
    <title>How Discord Supercharges Network Disks for Extreme Low Latency</title>
    <dc:date>2022-08-16T10:07:47+00:00</dc:date>
    <link>https://discord.com/blog/how-discord-supercharges-network-disks-for-extreme-low-latency</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Similar to a trick we used to use at Swrve to do roughly the same thing with EBS on AWS]]></description>
<dc:subject>discord google disks performance optimization scylladb md raid ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f663d3221476/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:discord"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:disks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scylladb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:md"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:raid"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://dotat.at/@/2022-06-27-tolower-swar.html">
    <title>tolower() in bulk at speed</title>
    <dc:date>2022-06-28T15:29:01+00:00</dc:date>
    <link>https://dotat.at/@/2022-06-27-tolower-swar.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[tolower() using SWAR (SIMD within a register) techniques -- nice hacks from Tony Finch

]]></description>
<dc:subject>c optimization performance hacks tolower swar simd</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:86b30b730c54/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:c"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tolower"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:swar"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:simd"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://mazzo.li/posts/fast-pipes.html">
    <title>How fast are Linux pipes anyway?</title>
    <dc:date>2022-06-04T16:33:40+00:00</dc:date>
    <link>https://mazzo.li/posts/fast-pipes.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Very enjoyable Linux hyper-optimization through splice and huge pages]]></description>
<dc:subject>kernel linux performance pipes vmsplice splice optimization syscalls unix</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8390af0dda94/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kernel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pipes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vmsplice"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:splice"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:syscalls"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/netty/netty/pull/10737/files">
    <title>SWAR indexOf byte search</title>
    <dc:date>2022-01-24T10:08:22+00:00</dc:date>
    <link>https://github.com/netty/netty/pull/10737/files</link>
    <dc:creator>jm</dc:creator><description><![CDATA[SIMD-Within-A-Register implementation of ByteBuf.indexOf() in Java, used in Netty. nice performance optimization technique]]></description>
<dc:subject>simd swar indexof bytebuffer java optimization performance search netty hacks</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b1bb44f3ef08/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:simd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:swar"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:indexof"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bytebuffer"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:search"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netty"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacks"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/WojciechMula/toys/tree/master/swar-utf8-length">
    <title>SWAR algorithm to count characters in a UTF-8 string</title>
    <dc:date>2021-11-29T10:18:31+00:00</dc:date>
    <link>https://github.com/WojciechMula/toys/tree/master/swar-utf8-length</link>
    <dc:creator>jm</dc:creator><description><![CDATA[I'm enjoying this world of SIMD hyperoptimization -- "SWAR" in this case refers to "SIMD within a register" -- performing SIMD parallel operations on data contained in a single processor register.]]></description>
<dc:subject>simd swar hacks performance optimization coding utf-8</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f56d6e491cf3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:simd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:swar"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:utf-8"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://archive.md/ilW8S#selection-777.0-781.1">
    <title>Facebook prioritized ‘angry’ emoji reaction posts in news feeds - The Washington Post</title>
    <dc:date>2021-10-27T08:47:52+00:00</dc:date>
    <link>https://archive.md/ilW8S#selection-777.0-781.1</link>
    <dc:creator>jm</dc:creator><description><![CDATA[“Anger and hate is the easiest way to grow on Facebook” - Frances Haugen]]></description>
<dc:subject>facebook hate anger negativity metrics kpis optimization engagement social-media</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:fcdf81881de7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:facebook"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hate"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:anger"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:negativity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kpis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:engagement"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:social-media"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://pkolaczk.github.io/overhead-of-optional/">
    <title>Overhead of Returning Optional Values in Java and Rust</title>
    <dc:date>2021-10-16T21:46:58+00:00</dc:date>
    <link>https://pkolaczk.github.io/overhead-of-optional/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[well, this is a little disappointing; even recent JVMs perform poorly in hotspots when Optional values are in use. Even nulls are not too good. tl;dr: primitives with "magic values" where needed are faster.]]></description>
<dc:subject>java rust optimization performance hotspots benchmarks optional null</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:950a505b2bef/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rust"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hotspots"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:benchmarks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optional"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:null"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://dl.acm.org/doi/10.1145/3064176.3064187">
    <title>The Unwritten Contract of Solid State Drives</title>
    <dc:date>2021-05-24T09:39:06+00:00</dc:date>
    <link>https://dl.acm.org/doi/10.1145/3064176.3064187</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>We perform a detailed vertical analysis of application performance atop a range of modern file systems and SSD FTLs. We formalize the "unwritten contract" that clients of SSDs should follow to obtain high performance, and conduct our analysis to uncover application and file system designs that violate the contract. Our analysis, which utilizes a highly detailed SSD simulation underneath traces taken from real workloads and file systems, provides insight into how to better construct applications, file systems, and FTLs to realize robust and sustainable performance.</blockquote>

(via Nelson)]]></description>
<dc:subject>via:nelson optimization performance ssd disks storage coding architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:faf7b0e9a292/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:nelson"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ssd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:disks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.jeffgeerling.com/blog/2020/raspberry-pi-usb-boot-uasp-trim-and-performance">
    <title>Raspberry Pi USB Boot - UASP, TRIM, and performance</title>
    <dc:date>2020-09-21T10:38:32+00:00</dc:date>
    <link>https://www.jeffgeerling.com/blog/2020/raspberry-pi-usb-boot-uasp-trim-and-performance</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>In the past few weeks, I reviewed USB drive performance on the Raspberry Pi 4, and the importance of UASP support for USB drive performance.
Both posts generated great discussion, and there were three things I wanted to cover in this follow-up, namely: Which drives support UASP; Real-world performance benchmarks; TRIM support.</blockquote>

]]></description>
<dc:subject>raspberry-pi optimization linux trim ssd filesystems usb</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:36695789d680/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:raspberry-pi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:trim"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ssd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:usb"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.reverberate.org/2020/05/29/hoares-rebuttal-bubble-sorts-comeback.html">
    <title>Hoare’s Rebuttal and Bubble Sort’s Comeback</title>
    <dc:date>2020-06-02T16:46:15+00:00</dc:date>
    <link>https://blog.reverberate.org/2020/05/29/hoares-rebuttal-bubble-sorts-comeback.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[New processor behaviour means everything we know about performance optimization is wrong again:

<blockquote>We’ve seen how crucial it is to understand data dependencies in order to optimize code. Especially hidden memory dependencies between load and stores can greatly influence performance of work loops. Understanding the data dependency graph of code is often where the real performance gains lie, yet very little attention is given to it in the blogosphere. I’ve read many articles about the impact of branch mispredictions, importance of data locality and caches, but much less about data dependencies. I bet that a question like “why are linked lists slow?” is answered by many in terms of locality, caches or unpredictable random memory access. At least I’ve heard those reasons often, even Stroustrup says as much. Those reasons can play a part, but it’s not the main reason. Fundamentally iterating a linked list has a load-to-use on the critical path, making it 5 times slower than iterating a flat array. Furthermore accessing flat arrays allow loop unrolling which can further improve ILP.</blockquote>

]]></description>
<dc:subject>data-dependencies sorting algorithms performance optimization coding</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:99913961e7a2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-dependencies"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sorting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.infoq.com/news/2020/01/blake3-fast-crypto-hash/">
    <title>BLAKE3</title>
    <dc:date>2020-02-24T17:28:59+00:00</dc:date>
    <link>https://www.infoq.com/news/2020/01/blake3-fast-crypto-hash/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['an Extremely Fast, Parallel Cryptographic Hash': BLAKE3's authors published a benchmark on an Intel Cascade Lake-SP 8275CL processor showing it to be 5x faster than BLAKE2 and 15x faster than SHA3-256.]]></description>
<dc:subject>blake3 blake hashing hashes algorithms speed performance optimization sha</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:386b7e9bbdfd/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:blake3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:blake"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hashing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hashes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:speed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sha"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://greenlab.di.uminho.pt/">
    <title>Green Software Lab</title>
    <dc:date>2020-02-24T10:55:08+00:00</dc:date>
    <link>https://greenlab.di.uminho.pt/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Lots of research on making sustainable, power-friendly software at a coding level]]></description>
<dc:subject>coding sustainability power green code optimization papers research</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ef4155d23f24/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sustainability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:power"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:green"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:code"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:papers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:research"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://calendar.perfplanet.com/2019/eco-worriers-saving-the-planet-one-unoptimized-website-at-a-time/">
    <title>Eco Worriers: Saving the Planet, One Unoptimized Website at a Time</title>
    <dc:date>2019-12-19T11:52:12+00:00</dc:date>
    <link>https://calendar.perfplanet.com/2019/eco-worriers-saving-the-planet-one-unoptimized-website-at-a-time/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Web sustainability performance checking]]></description>
<dc:subject>sustainability green web http optimization performance ad-blocking gwf</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1247cc866bc4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sustainability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:green"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ad-blocking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gwf"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://travisdowns.github.io/blog/2019/05/22/sorting.html">
    <title>Beating up on qsort</title>
    <dc:date>2019-05-27T14:41:11+00:00</dc:date>
    <link>https://travisdowns.github.io/blog/2019/05/22/sorting.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[an entertaining dive down a low-level performance-optimization rabbit hole, diving into radix sort on an array of integers in particular]]></description>
<dc:subject>sorting sort performance optimization radix-sort qsort algorithms</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:744ebaa46de8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sorting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sort"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:radix-sort"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:qsort"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://pages.cs.wisc.edu/~jignesh/publ/Revenge_of_the_Interpolation_Search.pdf">
    <title>_Efficiently y Searching In-Memory Sorted Arrays: Revenge of the Interpolation Search?_, Peter Van Sandt, Yannis Chronis, Jignesh M. Patel [pdf]</title>
    <dc:date>2019-05-15T10:04:47+00:00</dc:date>
    <link>http://pages.cs.wisc.edu/~jignesh/publ/Revenge_of_the_Interpolation_Search.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA['In this paper, we focus on the problem of searching sorted, in-memory datasets. This is a key data operation, and Binary Search is the de facto algorithm that is used in practice. We consider an alternative, namely Interpolation Search, which can take advantage of hardware trends by using complex calculations to save memory accesses. Historically, Interpolation Search was found to underperform compared to other search algorithms in this setting, despite its superior asymptotic complexity. Also,Interpolation Search is known to perform poorly on non-uniform data. To address these issues, we introduce SIP (Slope reuse Interpolation), an optimized implementation
of Interpolation Search, and TIP (Three point Interpolation), a new search algorithm that uses linear fractions to interpolate on non-uniform distributions. We evaluate these two algorithms against a similarly optimized Binary Search method using a variety of real and synthetic datasets. We show that SIP is up to 4 times faster on uniformly distributed data and TIP is 2-3 times faster on non-uniformly distributed data in some cases. We also design a meta-algorithm to switch between these different methods to automate picking the higher performing search algorithm, which depends on factors like data distribution.']]></description>
<dc:subject>papers pdf algorithms search interpolation binary-search sorted-data coding optimization performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2d559b6ee3d5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:papers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pdf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:search"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:interpolation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:binary-search"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sorted-data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://nullprogram.com/blog/2017/10/06/">
    <title>A Branchless UTF-8 Decoder</title>
    <dc:date>2017-10-09T10:27:09+00:00</dc:date>
    <link>http://nullprogram.com/blog/2017/10/06/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>This week I took a crack at writing a branchless UTF-8 decoder: a function that decodes a single UTF-8 code point from a byte stream without any if statements, loops, short-circuit operators, or other sorts of conditional jumps.  [...]  Why branchless? Because high performance CPUs are pipelined. That is, a single instruction is executed over a series of stages, and many instructions are executed in overlapping time intervals, each at a different stage.</blockquote>

Neat hack (via Tony Finch)]]></description>
<dc:subject>algorithms optimization unicode utf8 branchless coding c via:fanf</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e6a102583433/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unicode"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:utf8"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:branchless"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:c"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/AdoptOpenJDK/jitwatch">
    <title>AdoptOpenJDK/jitwatch</title>
    <dc:date>2017-08-24T16:22:31+00:00</dc:date>
    <link>https://github.com/AdoptOpenJDK/jitwatch</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Log analyser and visualiser for the HotSpot JIT compiler. Inspect inlining decisions, hot methods, bytecode, and assembly. View results in the JavaFX user interface.</blockquote>

]]></description>
<dc:subject>analysis java jvm performance tools debugging optimization jit</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:404ca57f5933/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:analysis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jit"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://codahale.com/usl4j-and-you/">
    <title>usl4j And You | codahale.com</title>
    <dc:date>2017-06-01T10:08:29+00:00</dc:date>
    <link>https://codahale.com/usl4j-and-you/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Coda Hale wrote a handy java library implementing a USL solver]]></description>
<dc:subject>usl scalability java performance optimization benchmarking measurement ops coda-hale</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c184c035e80a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:usl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:benchmarking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:measurement"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coda-hale"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://lemire.me/blog/2016/06/30/fast-random-shuffling/">
    <title>Fast random shuffling</title>
    <dc:date>2016-07-01T15:17:17+00:00</dc:date>
    <link>http://lemire.me/blog/2016/06/30/fast-random-shuffling/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[by avoiding division]]></description>
<dc:subject>coding algorithms performance optimization shuffle shuffling</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ce018caef02a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:shuffle"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:shuffling"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://twitter.com/akpurtell/status/698614296226312192">
    <title>Semisupervised Intern Descent</title>
    <dc:date>2016-02-13T22:01:51+00:00</dc:date>
    <link>https://twitter.com/akpurtell/status/698614296226312192</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Also known as "Graduate Student Descent", a common approach to hyperparameter tuning in machine learning -- ie. get an intern to sit there tweaking parameters until they find something approximating optimal performance]]></description>
<dc:subject>optimization funny terms terminology graduate-student-descent hyperparameters semisupervised-intern-descent tuning interns</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5eb66f4c558b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:funny"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:terms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:terminology"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graduate-student-descent"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hyperparameters"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:semisupervised-intern-descent"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:interns"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://bannalia.blogspot.fr/2015/06/cache-friendly-binary-search.html">
    <title>Cache-friendly binary search</title>
    <dc:date>2015-11-17T11:33:13+00:00</dc:date>
    <link>http://bannalia.blogspot.fr/2015/06/cache-friendly-binary-search.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[by reordering items to optimize locality.  Via aphyr's dad!]]></description>
<dc:subject>caches cache-friendly optimization data-locality performance coding algorithms</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:45e849ef0f46/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:caches"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cache-friendly"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-locality"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.elastic.co/blog/frame-of-reference-and-roaring-bitmaps">
    <title>Frame of Reference and Roaring Bitmaps</title>
    <dc:date>2015-09-23T13:50:16+00:00</dc:date>
    <link>https://www.elastic.co/blog/frame-of-reference-and-roaring-bitmaps</link>
    <dc:creator>jm</dc:creator><description><![CDATA[interesting performance-oriented algorithm tweak from Elastic/Lucene]]></description>
<dc:subject>lucene elasticsearch performance optimization roaring-bitmaps bitmaps frame-of-reference integers algorithms</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5dd4238d15a7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lucene"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:elasticsearch"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:roaring-bitmaps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bitmaps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:frame-of-reference"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:integers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://java-performance.info/hashmap-overview-jdk-fastutil-goldman-sachs-hppc-koloboke-trove-january-2015/">
    <title>Large Java HashMap performance overview</title>
    <dc:date>2015-09-06T21:53:32+00:00</dc:date>
    <link>http://java-performance.info/hashmap-overview-jdk-fastutil-goldman-sachs-hppc-koloboke-trove-january-2015/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Large HashMap overview: JDK, FastUtil, Goldman Sachs, HPPC, Koloboke, Trove – January 2015 version</blockquote>

]]></description>
<dc:subject>java performance hashmap hashmaps optimization fastutil hppc jdk koloboke trove data-structures</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d4bb2506c678/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hashmap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hashmaps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fastutil"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hppc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jdk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:koloboke"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:trove"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://vanillajava.blogspot.ie/2015/01/java-lambdas-and-low-latency.html">
    <title>Java lambdas and performance</title>
    <dc:date>2015-07-21T09:30:34+00:00</dc:date>
    <link>http://vanillajava.blogspot.ie/2015/01/java-lambdas-and-low-latency.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Lambdas in Java 8 introduce some unpredictable performance implications, due to reliance on escape analysis to eliminate object allocation on every lambda invocation.  Peter Lawrey has some details]]></description>
<dc:subject>lambdas java-8 java performance low-latency optimization peter-lawrey coding escape-analysis</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a175e4b13cb0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lambdas"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java-8"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:low-latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:peter-lawrey"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:escape-analysis"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.cloudera.com/blog/2015/05/working-with-apache-spark-or-how-i-learned-to-stop-worrying-and-love-the-shuffle/">
    <title>Working with Apache Spark: Or, How I Learned to Stop Worrying and Love the Shuffle | Cloudera Engineering Blog</title>
    <dc:date>2015-05-25T13:05:59+00:00</dc:date>
    <link>http://blog.cloudera.com/blog/2015/05/working-with-apache-spark-or-how-i-learned-to-stop-worrying-and-love-the-shuffle/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[some good Spark optimization tips]]></description>
<dc:subject>spark performance optimization rdd emr big-data cloudera tips akka</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c950623d822d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spark"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rdd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:emr"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:big-data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cloudera"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tips"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:akka"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://cglab.ca/~morin/misc/arraylayout/">
    <title>Memory Layouts for Binary Search</title>
    <dc:date>2015-05-09T11:04:44+00:00</dc:date>
    <link>http://cglab.ca/~morin/misc/arraylayout/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Key takeaway: <blockquote>Nearly uni­ver­sally, B-trees win when the data gets big enough. </blockquote>

]]></description>
<dc:subject>caches cpu performance optimization memory binary-search b-trees algorithms search memory-layout</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ed140ac75aca/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:caches"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cpu"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:binary-search"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:b-trees"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:search"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory-layout"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://twitter.com/igrigorik/status/587446362880344064/photo/1">
    <title>Rob Pike's 5 rules of optimization</title>
    <dc:date>2015-04-13T11:08:20+00:00</dc:date>
    <link>https://twitter.com/igrigorik/status/587446362880344064/photo/1</link>
    <dc:creator>jm</dc:creator><description><![CDATA[these are great.  I've run into rule #3 ("fancy algorithms are slow when n is small, and n is usually small") several times...]]></description>
<dc:subject>twitter rob-pike via:igrigorik coding rules laws optimization performance algorithms data-structures aphorisms</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8fb4a4612aa1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:twitter"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rob-pike"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:igrigorik"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rules"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:laws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aphorisms"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://thethemefoundry.com/blog/why-we-dont-use-a-cdn-spdy-ssl/">
    <title>Why we don't use a CDN: A story about SPDY and SSL</title>
    <dc:date>2015-01-10T22:36:45+00:00</dc:date>
    <link>https://thethemefoundry.com/blog/why-we-dont-use-a-cdn-spdy-ssl/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>All of our assets loaded via the CDN [to our client in Australia] in just under 5 seconds. It only took ~2.7s to get those same assets to our friends down under with SPDY. The performance with no CDN blew the CDN performance out of the water. It is just no comparison. In our case, it really seems that the advantages of SPDY greatly outweigh that of a CDN when it comes to speed.</blockquote>

]]></description>
<dc:subject>cdn spdy nginx performance web ssl tls optimization multiplexing tcp ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:80714627782c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cdn"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spdy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nginx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ssl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tls"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:multiplexing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/plasma-umass/coz">
    <title>coz</title>
    <dc:date>2014-12-22T08:45:44+00:00</dc:date>
    <link>https://github.com/plasma-umass/coz</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A causal profiler for C++.

<blockquote>Causal profiling is a novel technique to measure optimization potential. This measurement matches developers' assumptions about profilers: that optimizing highly-ranked code will have the greatest impact on performance. Causal profiling measures optimization potential for serial, parallel, and asynchronous programs without instrumentation of special handling for library calls and concurrency primitives. Instead, a causal profiler uses performance experiments to predict the effect of optimizations. This allows the profiler to establish causality: "optimizing function X will have effect Y," exactly the measurement developers had assumed they were getting all along.</blockquote>

I can see this being a good technique to stochastically discover race conditions and concurrency bugs, too.]]></description>
<dc:subject>optimization c++ performance coding profiling speed causal-profilers</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:236868a21738/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:c++"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:profiling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:speed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:causal-profilers"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.cloudera.com/blog/2009/12/7-tips-for-improving-mapreduce-performance/">
    <title>7 Tips for Improving MapReduce Performance | Cloudera Engineering Blog</title>
    <dc:date>2014-11-24T09:58:15+00:00</dc:date>
    <link>http://blog.cloudera.com/blog/2009/12/7-tips-for-improving-mapreduce-performance/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Good advice for Hadoop optimization]]></description>
<dc:subject>hadoop performance optimization cloudera map-reduce ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a7fd21901873/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hadoop"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cloudera"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:map-reduce"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/facebook/folly/blob/master/folly/docs/FBVector.md">
    <title>Facebook's drop-in replacement for std::vector</title>
    <dc:date>2014-09-01T09:02:26+00:00</dc:date>
    <link>https://github.com/facebook/folly/blob/master/folly/docs/FBVector.md</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Fixes some low-hanging fruit, performance-wise.

'Simply replacing std::vector with folly::fbvector (after having included the folly/FBVector.h header file) will improve the performance of your C++ code using vectors with common coding patterns. The improvements are always non-negative, almost always measurable, frequently significant, sometimes dramatic, and occasionally spectacular.'

(via Tony Finch)]]></description>
<dc:subject>c++ facebook performance algorithms vectors via:fanf optimization</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4903013d2867/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:c++"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:facebook"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vectors"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/cloudflare/lua-aho-corasick">
    <title>cloudflare/lua-aho-corasick</title>
    <dc:date>2014-08-29T21:55:32+00:00</dc:date>
    <link>https://github.com/cloudflare/lua-aho-corasick</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A nice Lua/C++ implementation of Aho-Corasick for fast string matching against multiple patterns (via JGC).  This uses an interesting technique to get better performance by compacting the data structure into a single buffer, to avoid following pointers all over RAM and busting the cache.]]></description>
<dc:subject>optimization speed performance aho-corasick tries string-matching strings algorithms lua c++ via:jgc</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:35ea65a2e9a1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:speed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aho-corasick"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tries"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:string-matching"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:strings"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lua"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:c++"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:jgc"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.sciencemag.org/content/345/6199/862.short">
    <title>'Addressing the rebalancing problem in bike-sharing systems' [paper]</title>
    <dc:date>2014-08-25T10:06:26+00:00</dc:date>
    <link>http://www.sciencemag.org/content/345/6199/862.short</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Many of the bike-sharing systems introduced around the world in the past 15 years have the same problem: Riders tend to take some routes and not others. As a result, the bikes tend to collect in a few places, which is a drag for users and a costly problem for the operators, who "rebalance" the system using trucks that take bikes from full stations to empty ones. Now, scientists are coming up with special algorithms to improve this process. One of them, developed by scientists at the Vienna University of Technology and the Austrian Institute of Technology, is now being tested in Vienna's bike-sharing system; another, developed at Cornell University, is already in use in New York City.</blockquote>

Timely -- here's what Dublin Bikes looked like this morning: https://twitter.com/jmason/status/503828246086295552

(via Andrew Caines)]]></description>
<dc:subject>cycling bike-sharing borisbikes dublinbikes rebalancing fleet availability optimization maths papers toread algorithms</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:774c4de5b6f2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cycling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bike-sharing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:borisbikes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dublinbikes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rebalancing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fleet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:availability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:maths"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:papers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:toread"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://code.facebook.com/posts/816473015039157/making-facebook-s-software-infrastructure-more-energy-efficient-with-autoscale/">
    <title>Making Facebook’s software infrastructure more energy efficient with Autoscale | Engineering Blog | Facebook Code</title>
    <dc:date>2014-08-09T11:05:55+00:00</dc:date>
    <link>https://code.facebook.com/posts/816473015039157/making-facebook-s-software-infrastructure-more-energy-efficient-with-autoscale/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Facebook's Autoscale service, which scales up/down the fleet in order to optimize power consumption; see also Google's Pegasus (http://csl.stanford.edu/~christos/publications/2014.pegasus.isca.pdf)]]></description>
<dc:subject>scaling via:eoinbrazil facebook autoscaling power optimization</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0694df54356f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:eoinbrazil"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:facebook"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:autoscaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:power"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://cdn.oreillystatic.com/en/assets/1/event/44/TCP%20and%20the%20Lower%20Bound%20of%20Web%20Performance%20Presentation.pdf">
    <title>'TCP And The Lower Bound of Web Performance' [pdf, slides]</title>
    <dc:date>2014-08-05T11:22:32+00:00</dc:date>
    <link>http://cdn.oreillystatic.com/en/assets/1/event/44/TCP%20and%20the%20Lower%20Bound%20of%20Web%20Performance%20Presentation.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA[John Rauser, Velocity, June 2010.  Good data on real-world web perf based on the limitations which TCP and the speed of light impose]]></description>
<dc:subject>tcp speed-of-light performance web optimization john-rauser</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1a39b9150f28/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:speed-of-light"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:john-rauser"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf">
    <title>&quot;Pitfalls of Object Oriented Programming&quot;, SCEE R&amp;D</title>
    <dc:date>2014-07-10T14:02:00+00:00</dc:date>
    <link>http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Good presentation discussing "data-oriented programming" -- the concept of optimizing memory access speed by laying out large data in a columnar format in RAM, rather than naively in the default layout that OOP design suggests]]></description>
<dc:subject>columnar ram memory optimization coding c++ oop data-oriented-programming data cache performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:09dba48c01ad/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:columnar"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ram"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:c++"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:oop"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-oriented-programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cache"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://shipilev.net/blog/2014/exceptional-performance/">
    <title>Exceptional Performance</title>
    <dc:date>2014-05-14T13:09:42+00:00</dc:date>
    <link>http://shipilev.net/blog/2014/exceptional-performance/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Good benchmark data on the performance of JVM exceptions
]]></description>
<dc:subject>java jvm exceptions benchmarking performance optimization coding</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7d2c8fedbc9e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:exceptions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:benchmarking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://druid.io/blog/2014/02/18/hyperloglog-optimizations-for-real-world-systems.html">
    <title>Druid | How We Scaled HyperLogLog: Three Real-World Optimizations</title>
    <dc:date>2014-04-17T08:56:10+00:00</dc:date>
    <link>http://druid.io/blog/2014/02/18/hyperloglog-optimizations-for-real-world-systems.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[3 optimizations Druid.io have made to the HLL algorithm to scale it up for production use in Metamarkets: compacting registers (fixes a bug with unions of multiple HLLs); a sparse storage format (to optimize space); faster lookups using a lookup table.]]></description>
<dc:subject>druid.io metamarkets scaling hyperloglog hll algorithms performance optimization counting estimation</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:cdabba572a8b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:druid.io"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metamarkets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hyperloglog"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hll"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:counting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:estimation"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://engineering.linkedin.com/garbage-collection/garbage-collection-optimization-high-throughput-and-low-latency-java-applications">
    <title>Garbage Collection Optimization for High-Throughput and Low-Latency Java Applications</title>
    <dc:date>2014-04-08T21:54:13+00:00</dc:date>
    <link>http://engineering.linkedin.com/garbage-collection/garbage-collection-optimization-high-throughput-and-low-latency-java-applications</link>
    <dc:creator>jm</dc:creator><description><![CDATA[LinkedIn talk about the GC opts they used to optimize the Feed. good detail]]></description>
<dc:subject>performance optimization linkedin java jvm gc tuning</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:77cabe371f7c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linkedin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://normanmaurer.me/presentations/2014-facebook-eng-netty/slides.html">
    <title>Netty Best Practices</title>
    <dc:date>2014-04-01T22:01:24+00:00</dc:date>
    <link>http://normanmaurer.me/presentations/2014-facebook-eng-netty/slides.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA['a.k.a. Faster == Better'.  Slides from a talk given at Facebook on 19th March 2014 by Norman Maurer]]></description>
<dc:subject>netty java performance optimization facebook slides presentations</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:87af68a8eb5c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netty"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:facebook"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slides"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:presentations"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/netty/netty/commit/6efac6179e1e13e6caba2cec6109ce27862efc9a">
    <title>[#1259] Add optimized queue for SCMP pattern and use it in NIO and nativ... · 6efac61 · netty/netty</title>
    <dc:date>2014-03-31T17:03:53+00:00</dc:date>
    <link>https://github.com/netty/netty/commit/6efac6179e1e13e6caba2cec6109ce27862efc9a</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Interesting -- Netty has imported an optimized ASL2-licensed MPSC queue implementation from Akka (presumably for performance raisins)]]></description>
<dc:subject>performance optimization open-source mpsc queues data-structures netty akka java</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:69f7fd9a90b7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:open-source"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mpsc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queues"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netty"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:akka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://java-is-the-new-c.blogspot.ie/2013/07/impact-of-large-primitive-arrays-blobs.html">
    <title>Impact of large primitive arrays (BLOBS) on JVM Garbage Collection</title>
    <dc:date>2014-03-19T12:12:51+00:00</dc:date>
    <link>http://java-is-the-new-c.blogspot.ie/2013/07/impact-of-large-primitive-arrays-blobs.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[some nice graphs and data on CMS performance, with/without -XX:ParGCCardsPerStrideChunk]]></description>
<dc:subject>cms java jvm performance optimization tuning off-heap-storage memory</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:026572f118c8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:off-heap-storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://twitter.com/jmason/status/423409032431271936">
    <title>Branchless hex-to-decimal conversion hack</title>
    <dc:date>2014-01-15T11:01:35+00:00</dc:date>
    <link>https://twitter.com/jmason/status/423409032431271936</link>
    <dc:creator>jm</dc:creator><description><![CDATA[via @simonebordet, on the mechanical-sympathy list: ((c & 0x1F) + ((c >> 6) * 0x19) – 0x10)]]></description>
<dc:subject>hacks one-liners coding performance optimization hex conversion numbers ascii</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:483c084ba47d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:one-liners"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hex"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:conversion"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:numbers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ascii"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://plus.google.com/+IlyaGrigorik/posts/1sxencNkbNS">
    <title>Google Fonts recently switched to using Zopfli</title>
    <dc:date>2014-01-14T11:11:31+00:00</dc:date>
    <link>https://plus.google.com/+IlyaGrigorik/posts/1sxencNkbNS</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Google Fonts recently switched to using new Zopfli compression algorithm:  the fonts are ~6% smaller on average, and in some cases up to 15% smaller! [...]
What's Zopfli? It's an algorithm that was developed by the compression team at Google that delivers ~3~8% bytesize improvement when compared to gzip with maximum compression. This byte savings comes at a cost of much higher encoding cost, but the good news is, fonts are static files and decompression speed is exactly the same. Google Fonts pays the compression cost once and every clients gets the benefit of smaller download. If you’re curious to learn more about Zopfli: http://bit.ly/Y8DEL4</blockquote>

]]></description>
<dc:subject>zopfli compression gzip fonts google speed optimization</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:fb4229faa0c9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:zopfli"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:compression"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gzip"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fonts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:speed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.slideshare.net/cpwatson/cpn302-yourlinuxamioptimizationandperformance">
    <title>Netflix: Your Linux AMI: optimization and performance [slides]</title>
    <dc:date>2013-12-21T20:50:48+00:00</dc:date>
    <link>http://www.slideshare.net/cpwatson/cpn302-yourlinuxamioptimizationandperformance</link>
    <dc:creator>jm</dc:creator><description><![CDATA[a fantastic bunch of low-level kernel tweaks and tunables which Netflix have found useful in production to maximise productivity of their fleet.  Interesting use of SCHED_BATCH process scheduler class for batch processes, in particular.  Also, great docs on their experience with perf and SystemTap.  Perf really looks like a tool I need to get to grips with...]]></description>
<dc:subject>netflix aws tuning ami perf systemtap tunables sched_batch batch hadoop optimization performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5c1292b5cc15/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netflix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ami"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:perf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:systemtap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tunables"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sched_batch"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:batch"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hadoop"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://stereopsis.com/radix.html">
    <title>stereopsis : graphics : radix tricks</title>
    <dc:date>2013-12-19T17:13:59+00:00</dc:date>
    <link>http://stereopsis.com/radix.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[some nice super-optimized Radix Sort code which handles floating point values.  See also http://codercorner.com/RadixSortRevisited.htm for more info on the histogramming/counter concept]]></description>
<dc:subject>sorting programming coding algorithms radix-sort optimization floating-point</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:456ae3d8f5c1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sorting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:radix-sort"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:floating-point"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://mentablog.soliveirajr.com/2012/12/asynchronous-logging-versus-memory-mapped-files/">
    <title>Asynchronous logging versus Memory Mapped Files</title>
    <dc:date>2013-11-20T11:50:21+00:00</dc:date>
    <link>http://mentablog.soliveirajr.com/2012/12/asynchronous-logging-versus-memory-mapped-files/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Interesting article around using mmap'd files from Java using RandomAccessFile.getChannel().map(), which allows them to be accessed directly as a ByteBuffer.  together with Atomic variable lazySet() operations, this provides pretty excellent performance results on low-latency writes to disk.  See also: http://psy-lob-saw.blogspot.ie/2012/12/atomiclazyset-is-performance-win-for.html]]></description>
<dc:subject>atomic lazyset putordered jmm java synchronization randomaccessfile bytebuffers performance optimization memory disk queues</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e0eaf36231f0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:atomic"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lazyset"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:putordered"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jmm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:synchronization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:randomaccessfile"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bytebuffers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:disk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queues"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://psy-lob-saw.blogspot.ie/2013/10/spsc-revisited-part-iii-fastflow-sparse.html">
    <title>SPSC revisited part III - FastFlow + Sparse Data</title>
    <dc:date>2013-10-07T09:51:25+00:00</dc:date>
    <link>http://psy-lob-saw.blogspot.ie/2013/10/spsc-revisited-part-iii-fastflow-sparse.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[holy moly.  This is some heavily-optimized mechanical-sympathy Java code.  By using a sparse data structure, cache-aligned fields, and wait-free low-level CAS concurrency primitives via sun.misc.Unsafe, a single-producer/single-consumer queue implementation goes pretty damn fast compared to the current state of the art]]></description>
<dc:subject>nitsanw optimization concurrency java jvm cas spsc queues data-structures algorithms</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:76f60b5fe219/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nitsanw"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:concurrency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cas"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spsc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queues"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://low-latency.com/article/groundbreaking-results-high-performance-trading-fpga-and-x86-technologies">
    <title>Groundbreaking Results for High Performance Trading with FPGA and x86 Technologies</title>
    <dc:date>2013-10-02T12:54:33+00:00</dc:date>
    <link>http://low-latency.com/article/groundbreaking-results-high-performance-trading-fpga-and-x86-technologies</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>The enhancement in performance was achieved by providing a fast-path where trades are executed directly by the FPGA under the control of trigger rules processed by the x86 based functions. The latency is reduced further by two additional techniques in the FPGA – inline parsing and pre-emption.  As market data enters the switch, the Ethernet frame is parsed serially as bits arrive, allowing partial information to be extracted and matched before the whole frame has been received. Then, instead of waiting until the end of a potential triggering input packet, pre-emption is used to start sending the overhead part of a response which contains the Ethernet, IP, TCP and FIX headers. This allows completion of an outgoing order almost immediately after the end of the triggering market feed packet.</blockquote>

Insane stuff. (Via Martin Thompson)]]></description>
<dc:subject>via:martin-thompson insane speed low-latency fpga fast-path trading stock-markets performance optimization ethernet</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e1e6cba06648/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:martin-thompson"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:insane"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:speed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:low-latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fpga"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fast-path"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:trading"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stock-markets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ethernet"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.infoq.com/articles/tuning-tips-G1-GC">
    <title>Tips for Tuning the Garbage First Garbage Collector</title>
    <dc:date>2013-09-18T21:34:06+00:00</dc:date>
    <link>http://www.infoq.com/articles/tuning-tips-G1-GC</link>
    <dc:creator>jm</dc:creator><dc:subject>g1gc gc java jvm tuning ops optimization</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6b12d8d218aa/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:g1gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://edinburghhacklab.com/2013/09/probabalistic-scraping-of-plain-text-tables/">
    <title>Probabalistic Scraping of Plain Text Tables</title>
    <dc:date>2013-09-08T22:49:35+00:00</dc:date>
    <link>http://edinburghhacklab.com/2013/09/probabalistic-scraping-of-plain-text-tables/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[a nifty hack.

<blockquote>Recently I have been banging my head trying to import a ton of OCR acquired data expressed in tabular form. I think I have come up with a neat approach using probabilistic reasoning combined with mixed integer programming. The method is pretty robust to all sorts of real world issues. In particular, the method leverages topological understanding of tables, encodes it declaratively into a mixed integer/linear program, and integrates weak probabilistic signals to classify the whole table in one go (at sub second speeds). This method can be used for any kind of classification where you have strong logical constraints but noisy data.</blockquote>

(via proggit)

]]></description>
<dc:subject>scraping tables ocr probabilistic linear-programming optimization machine-learning via:proggit</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:aea5b4ffbc36/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scraping"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tables"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ocr"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:probabilistic"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linear-programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:machine-learning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:proggit"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.infoq.com/articles/Java_Garbage_Collection_Distilled">
    <title>Java Garbage Collection Distilled</title>
    <dc:date>2013-06-19T10:07:19+00:00</dc:date>
    <link>http://www.infoq.com/articles/Java_Garbage_Collection_Distilled</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Martin Thompson lays it out:

<blockquote>Serial, Parallel, Concurrent, CMS, G1, Young Gen, New Gen, Old Gen, Perm Gen, Eden, Tenured, Survivor Spaces, Safepoints, and the hundreds of JVM start-up flags. Does this all baffle you when trying to tune the garbage collector while trying to get the required throughput and latency from your Java application? If it does then don’t worry, you are not alone. Documentation describing garbage collection feels like man pages for an aircraft. Every knob and dial is detailed and explained but nowhere can you find a guide on how to fly. This article will attempt to explain the tradeoffs when choosing and tuning garbage collection algorithms for a particular workload.</blockquote>

]]></description>
<dc:subject>gc java garbage-collection coding cms g1 jvm optimization</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f59114d2c748/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:garbage-collection"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:g1"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.aggregateknowledge.com/2011/12/12/big-memory-part-4/">
    <title>Big Memory, Part 4</title>
    <dc:date>2013-06-14T16:15:53+00:00</dc:date>
    <link>http://blog.aggregateknowledge.com/2011/12/12/big-memory-part-4/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[good microbenchmarking of a bunch of Java collections; Trove, fastutil, PCJ, mahout-collections, hppc]]></description>
<dc:subject>java collections benchmarks performance speed coding data-structures optimization</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:bf55fa5e7127/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:collections"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:benchmarks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:speed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://fastutil.di.unimi.it/">
    <title>fastutil</title>
    <dc:date>2013-06-14T16:09:12+00:00</dc:date>
    <link>http://fastutil.di.unimi.it/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>fastutil extends the Java™ Collections Framework by providing type-specific maps, sets, lists and queues with a small memory footprint and fast access and insertion; provides also big (64-bit) arrays, sets and lists, and fast, practical I/O classes for binary and text files. It is free software distributed under the Apache License 2.0. It requires Java 6 or newer.</blockquote>

used by Facebook (along with Apache Giraph, Netty, Unsafe) to speed up "weekend Hive jobs" to "coffee breaks". http://www.slideshare.net/nitayj/2013-0603-berlin-buzzwords]]></description>
<dc:subject>via:highscalability facebook giraph optimization java speed fastutil collections data-structures</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0d6dc4177b25/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:highscalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:facebook"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:giraph"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:speed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fastutil"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:collections"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>