[HN Gopher] Java: Why Core-to-Core Latency Matters
___________________________________________________________________
Java: Why Core-to-Core Latency Matters
Author : rntn
Score : 16 points
Date : 2022-05-20 18:21 UTC (4 hours ago)
(HTM) web link (chronicle.software)
(TXT) w3m dump (chronicle.software)
| kosherhurricane wrote:
| > it's surprising how few Java developers with 10+ years of
| experience have a deep knowledge of the underlying hardware.
|
| What fraction of Java software needs the lowest possible core-to-
| core latency? Around 0%?
|
| But hey, he's a cool, specialized programmer who knows these
| things, and need to share this important knowledge with someone.
| And yet, the article never answers the question it asks. What
| impact did pinning cores have on their application? 5%
| improvement? 20% improvement?
|
| I've made performance improvements by manually removing all
| bounds checks in a hot path. It made about 3% improvement to the
| total performance. Was it worth it? For my application, sure. Do
| I think other engineers are dumb because they don't do rigorous
| bounds check elimination? No.
| metadat wrote:
| Agreed, "why does it matter?"
|
| For now, it absolutely doesn't, and to 99.99999999999999% of
| humanity, it never will.
| melony wrote:
| Did you actually read the article? The blog post is by an
| algorithmic trading company. Finance makes up a rather large
| chunk of Java usage in industry. Not all applications are CRUD
| apps.
| arinlen wrote:
| > _Not all applications are CRUD apps._
|
| In the general picture, practically all apps are CRUD and
| virtually none are high-performance trading apps.
|
| OP is right: the number of times that core-to-core latency
| matters to a problem domain is practically zero. Trying do
| fine-tune that with Java might be in demand as much as being
| able to develop WebApps with brainfuck.
| karmakaze wrote:
| Title should have been When rather than Why.
___________________________________________________________________
(page generated 2022-05-20 23:01 UTC)