some more lottes & fluery.
This commit is contained in:
ed committed
1 parent
927025d052
commit
ab5e01c7b6
19 files changed
+892
No files matched your search
@@ -0,0 +1,72 @@
|
||||
---
|
||||
title: "Operands/time = Perf"
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/NOTimothyLottes/status/2091652388184572155"
|
||||
author: "NOTimothyLottes"
|
||||
handle: NOTimothyLottes
|
||||
post_id: "2091652388184572155"
|
||||
date: 2026-08-23
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "Operands/time = Perf"
|
||||
in_reply_to: ""
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/NOTimothyLottes/status/2091652388184572155
|
||||
- Author: NOTimothyLottes (@NOTimothyLottes)
|
||||
- Posted: 2026-08-23 22:22:45
|
||||
|
||||
## Thread
|
||||
|
||||
**1/** @NOTimothyLottes
|
||||
|
||||
Operands/time = Perf
|
||||
Mitigating amplifiers
|
||||
a. Register reuse [avoid load]
|
||||
b. Operand caching [avoid reg file access]
|
||||
c. Destination reuse [forwarding]
|
||||
d. Scalar constants + SIMD [broadcast]
|
||||
e. Parallel subword extraction [inline decompression]
|
||||
|
||||
**2/** @NOTimothyLottes
|
||||
|
||||
f. Banking [for multi-port]
|
||||
|
||||
If reg file supports only 1 store source/port/clk then you'd need forwarding to open a clock to do a parallel load (with alu) for the given port. Likewise you'd need an isa "last use" (avoid reg write) to get parallel store [into reg file] (with alu).
|
||||
|
||||
**3/** @NOTimothyLottes
|
||||
|
||||
Seems like the best one can do on a xilinx fpga is 6 clock pipeline
|
||||
[lutRAM]->[CLB1]->[DSP.ab]->[DSP.m]->[DSP.p]->[CLB2]->[lutRAM]
|
||||
Where CLB1 does {DSP.p to multiplier operand forwarding to get 4 clock IMAD latency}. And accumulation uses internal c=p routing for "no" latency.
|
||||
|
||||
**4/** @NOTimothyLottes
|
||||
|
||||
CLB2 is injection for loads from BRAM (when regfile port store isn't needed for DSP.p). If register file is 3 way banked, and direct mapped (bank 0 -> CLB -> DSP.A), then there are 3 reads/clk and 3 writes/clk ... given a value is not needed in all banks, lots of pipelinabiliy
|
||||
|
||||
**5/** @NOTimothyLottes
|
||||
|
||||
But most FPGA SIMD soft processors stick to even longer pipelines, direct regfile in BRAM, and no usage of DSP P->C forwarding (accumulation). Which means they have heavy dilution of their memory/time (too many parallel tasks).
|
||||
|
||||
**6/** @NOTimothyLottes
|
||||
|
||||
I think it's better to hand unroll parallel tasks into one assembled instruction stream, expose variable latency {forwarded vs round-trip through reg file} --vs-- the alternative of HW managed multi-threading.
|
||||
|
||||
**7/** @NOTimothyLottes
|
||||
|
||||
However, how many arch have actual instruction stream compression? None? (x86 doesn't really count). If you build around massive unrolling, you are doing the same stuff with offset'ed operands -> so obviously wants compression, else a tiny I$ won't survive
|
||||
|
||||
**8/** @NOTimothyLottes
|
||||
|
||||
Ok, I lied, there are some historic examples of multi-component + SIMD which leverage a {1,2,3,4} ISA bitfield to repeat the op/compent, or SIMD itself via looping instruction -- which technically is a great example of "compression"
|
||||
|
||||
**9/** @NOTimothyLottes
|
||||
|
||||
Getting the 3x local memory vs operand data rate amplifier, along with memory hierarchy pipelining, sorted is perhaps the most important thing for realized IPC, but there is still the 100x operand vs external bandwidth mitigation which defines the platform ...
|
||||
+52
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "One downsides to being a left justified machine and emulated on a FPGA is that one cannot use the built-in DSP's rounding capability through CIN."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/NOTimothyLottes/status/2092088375205359693"
|
||||
author: "NOTimothyLottes"
|
||||
handle: NOTimothyLottes
|
||||
post_id: "2092088375205359693"
|
||||
date: 2026-08-25
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "One downsides to being a left justified machine and emulated on a FPGA is that one cannot use the built-in DSP's rounding capability through CIN."
|
||||
in_reply_to: ""
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/NOTimothyLottes/status/2092088375205359693
|
||||
- Author: NOTimothyLottes (@NOTimothyLottes)
|
||||
- Posted: 2026-08-25 03:15:12
|
||||
|
||||
## Thread
|
||||
|
||||
**1/** @NOTimothyLottes
|
||||
|
||||
One downsides to being a left justified machine and emulated on a FPGA is that one cannot use the built-in DSP's rounding capability through CIN. So the end of accumulation requires a long latency feedback of the MSB of P to effect LSB bits of C for final add before right shift
|
||||
|
||||
**2/** @NOTimothyLottes
|
||||
|
||||
Yields 2 options - that accumulation + expensive post accumulation rounding --OR-- round after each MUL by setting the shifted out LSBs of C based on XOR(A,B) MSBs and don't accumulate (no P) which means always a fixed 4 clk ALU latency [with forwarding]
|
||||
|
||||
**3/** @NOTimothyLottes
|
||||
|
||||
For reference - Left-justified signed IMAD: Reduced to a 3-bit machine with a 16-bit accumulator for testing [below], being used as a C model proxy for a 24-bit A expanded to 7 series 25-bits (the LSB 0), with a 18-bit B, and 24-bit C (and extracted 24-bit result in same slot).
|
||||
|
||||
|
||||
|
||||
**4/** @NOTimothyLottes
|
||||
|
||||
This is for a vector SIMD (a soft GPU). Effectively a 32-bit memory driving a 24-bit ALU with variable sub-word size {24,16,8,4} as inline compression/decompression HW. Noticed sub-word extraction gets less expensive if one uses SR on the registering flip-flop for LSB zeros.
|
||||
|
||||
**5/** @NOTimothyLottes
|
||||
|
||||
Been working on my little FPGA GPU project for quite some time, mostly trying to engineer out enough of the pipeline as mapped to CLBs/DSPs/dRAMs/bRAMs with basic rules like one CLB deep per pipeline stage per registering and no cascading, etc, to target peak frequency ...
|
||||
|
||||
**6/** @NOTimothyLottes
|
||||
|
||||
I'm engineering some horribly unconventional things, like a one instruction SIMD VLIW ALU (IMAD) with modifiers and surrounding support for binary searching "a*b/c" and "sqrt", etc, paired to a sub-word bit extraction/packing unit, sign conditional swap store to banked reg file
|
||||
@@ -97,3 +97,5 @@ tags:
|
||||
- [[archive/threads/NOTimothyLottes/2026-07-19-probably-shouldnt-consider-this-but-apparently]]
|
||||
- [[archive/threads/NOTimothyLottes/2026-07-22-working-through-rough-draft-of-assembly-for-a]]
|
||||
- [[archive/threads/NOTimothyLottes/2026-08-02-re-fpga-land-alus-im-firmly-distracted-by-an]]
|
||||
- [[archive/threads/NOTimothyLottes/2026-08-23-operands-time-perf]]
|
||||
- [[archive/threads/NOTimothyLottes/2026-08-25-one-downsides-to-being-a-left-justified-machine]]
|
||||
+63
@@ -0,0 +1,63 @@
|
||||
---
|
||||
title: "@rfleury Saw a Casey Muratori video about people who think in single unit lifetimes vs group allocations etc yesterday."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/AnthonyPatch15/status/1917436903994818849"
|
||||
author: "Anthony Patch"
|
||||
handle: AnthonyPatch15
|
||||
post_id: "1917436903994818849"
|
||||
date: 2025-04-30
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- rfleury
|
||||
description: "@rfleury Saw a Casey Muratori video about people who think in single unit lifetimes vs group allocations etc yesterday."
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1917431895786414425"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/AnthonyPatch15/status/1917436903994818849
|
||||
- Author: Anthony Patch (@AnthonyPatch15)
|
||||
- Posted: 2025-04-30 04:32:36
|
||||
|
||||
## Branch
|
||||
|
||||
**1/** @AnthonyPatch15
|
||||
|
||||
@rfleury
|
||||
|
||||
Saw a Casey Muratori video about people who think in single unit lifetimes vs group allocations etc yesterday.
|
||||
And while I actually agree with both of you, I am believe most of these modern C++ semantics / Rust tries to solve larger team problems.
|
||||
|
||||
**2/** @rfleury
|
||||
|
||||
@AnthonyPatch15
|
||||
|
||||
There is no evidence to support the idea that these constructs are inherently necessary in larger teams.
|
||||
|
||||
**3/** @AnthonyPatch15
|
||||
|
||||
@rfleury
|
||||
|
||||
No I don’t intend to try and prove it, they are by nature not.
|
||||
But what tends to happen in most teams I’ve been part of is that they have some people who are super good and rigorous but also a lot of people who don’t really know what they’re doing - these help the second group.
|
||||
|
||||
**4/** @survotreson
|
||||
|
||||
@AnthonyPatch15 @rfleury
|
||||
|
||||
Then the people who don't know what they're doing maybe shouldn't participate and go train ? Kinda sounds like optimizing for the wrong thing here
|
||||
|
||||
**5/** @AnthonyPatch15
|
||||
|
||||
@survotreson @rfleury
|
||||
|
||||
In an ideal world yes, never been at a workplace that works like this.
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a]]
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "@rfleury There is exactly zero pain in debugging unique_ptr variables these days."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/DomWitczak/status/1917469208335507559"
|
||||
author: "Dominik Witczak"
|
||||
handle: DomWitczak
|
||||
post_id: "1917469208335507559"
|
||||
date: 2025-04-30
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- rfleury
|
||||
description: "@rfleury There is exactly zero pain in debugging unique_ptr variables these days."
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1917431895786414425"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/DomWitczak/status/1917469208335507559
|
||||
- Author: Dominik Witczak (@DomWitczak)
|
||||
- Posted: 2025-04-30 06:40:58
|
||||
|
||||
## Branch
|
||||
|
||||
**1/** @DomWitczak
|
||||
|
||||
@rfleury
|
||||
|
||||
There is exactly zero pain in debugging unique_ptr variables these days. Even with gdb.
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a]]
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "@rfleury I miss the point you are trying to make"
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/KirillKiriche11/status/1917466585490678240"
|
||||
author: "Kirichewski Lorenso"
|
||||
handle: KirillKiriche11
|
||||
post_id: "1917466585490678240"
|
||||
date: 2025-04-30
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- rfleury
|
||||
description: "@rfleury I miss the point you are trying to make"
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1917431895786414425"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/KirillKiriche11/status/1917466585490678240
|
||||
- Author: Kirichewski Lorenso (@KirillKiriche11)
|
||||
- Posted: 2025-04-30 06:30:33
|
||||
|
||||
## Branch
|
||||
|
||||
**1/** @KirillKiriche11
|
||||
|
||||
@rfleury
|
||||
|
||||
I miss the point you are trying to make
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a]]
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "@rfleury This isn't such a strong argument considering there's a \"leak\" with the regular call to `new`."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/MoveZig4/status/1917463363300610136"
|
||||
author: "Kyle"
|
||||
handle: MoveZig4
|
||||
post_id: "1917463363300610136"
|
||||
date: 2025-04-30
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- rfleury
|
||||
description: "@rfleury This isn't such a strong argument considering there's a \"leak\" with the regular call to `new`."
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1917431895786414425"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/MoveZig4/status/1917463363300610136
|
||||
- Author: Kyle (@MoveZig4)
|
||||
- Posted: 2025-04-30 06:17:45
|
||||
|
||||
## Branch
|
||||
|
||||
**1/** @MoveZig4
|
||||
|
||||
@rfleury
|
||||
|
||||
This isn't such a strong argument considering there's a "leak" with the regular call to `new`. To my untrained eye under clang-19 the generated assembly for unique_ptr is a bit smaller/slimmer, with less stack usage - https://godbolt.org/z/sxejEsbe4 - can't turn on -O anything sadly
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a]]
|
||||
+73
@@ -0,0 +1,73 @@
|
||||
---
|
||||
title: "@rfleury Too much words, but unique_ptr is*really* zero cost."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/Pps831/status/1917545684372447392"
|
||||
author: "Pps831"
|
||||
handle: Pps831
|
||||
post_id: "1917545684372447392"
|
||||
date: 2025-04-30
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- rfleury
|
||||
description: "@rfleury Too much words, but unique_ptr is*really* zero cost."
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1917431895786414425"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/Pps831/status/1917545684372447392
|
||||
- Author: Pps831 (@Pps831)
|
||||
- Posted: 2025-04-30 11:44:52
|
||||
|
||||
## Branch
|
||||
|
||||
**1/** @Pps831
|
||||
|
||||
@rfleury
|
||||
|
||||
Too much words, but unique_ptr is*really* zero cost. There is no way to go negative in cost there, no matter how much you wish for it 🤣
|
||||
|
||||
**2/** @rfleury
|
||||
|
||||
@Pps831
|
||||
|
||||
I recommend you learn to read
|
||||
|
||||
**3/** @Pps831
|
||||
|
||||
@rfleury
|
||||
|
||||
I’m ok. But you should at least try to validate if unique_par is zero cost or not. Also, in case you were really complaining about shared_ptr - try to cook something equivalent in c (not just “smart” ptr with ref count, but equivalent)
|
||||
|
||||
**4/** @rfleury
|
||||
|
||||
@Pps831
|
||||
|
||||
It isn’t zero cost.
|
||||
|
||||
**5/** @Pps831
|
||||
|
||||
@rfleury
|
||||
|
||||
Shared_ptr? Off course, it’s really heavy, but it has incredibly useful functionality.
|
||||
|
||||
**6/** @rfleury
|
||||
|
||||
@Pps831
|
||||
|
||||
No, both of them. Neither are useful compared to the alternatives.
|
||||
|
||||
**7/** @Pps831
|
||||
|
||||
@rfleury
|
||||
|
||||
If you “really” need the functionality - then it’s great. Most uses don’t really need shared_ptr. If you don’t use it along with “weak_ptr” then you don’t really need it. If you complain about all the allocations, it has solution for the problem: enable_shared_from_this
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a]]
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "@rfleury Generated assembly or other supposedly better ‘hand-written’ options for memory management are IMO just distractions when talking about unique_ptr."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/Wouter_Bijlsma/status/1917520025348436222"
|
||||
author: "Wouter Bijlsma"
|
||||
handle: Wouter_Bijlsma
|
||||
post_id: "1917520025348436222"
|
||||
date: 2025-04-30
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- rfleury
|
||||
description: "@rfleury Generated assembly or other supposedly better ‘hand-written’ options for memory management are IMO just distractions when talking about unique_ptr."
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1917431895786414425"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/Wouter_Bijlsma/status/1917520025348436222
|
||||
- Author: Wouter Bijlsma (@Wouter_Bijlsma)
|
||||
- Posted: 2025-04-30 10:02:54
|
||||
|
||||
## Branch
|
||||
|
||||
**1/** @Wouter_Bijlsma
|
||||
|
||||
@rfleury
|
||||
|
||||
Generated assembly or other supposedly better ‘hand-written’ options for memory management are IMO just distractions when talking about unique_ptr. The point of it is to signal and enforce ownership in an API, which can only be a good thing, no? Don’t understand the hate 🤨
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a]]
|
||||
+39
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: "@rfleury I bet std comitee wrote thousands of lines for this"
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/anilcanglk12/status/1917498526285603216"
|
||||
author: "Anılcan Gülkaya"
|
||||
handle: anilcanglk12
|
||||
post_id: "1917498526285603216"
|
||||
date: 2025-04-30
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- rfleury
|
||||
description: "@rfleury I bet std comitee wrote thousands of lines for this"
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1917431895786414425"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/anilcanglk12/status/1917498526285603216
|
||||
- Author: Anılcan Gülkaya (@anilcanglk12)
|
||||
- Posted: 2025-04-30 08:37:28
|
||||
|
||||
## Branch
|
||||
|
||||
**1/** @anilcanglk12
|
||||
|
||||
@rfleury
|
||||
|
||||
I bet std comitee wrote thousands of lines for this
|
||||
|
||||
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a]]
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "@rfleury I'd use C more if attribute(__cleanup__) was standard and a little less cumbersome."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/eclectocrat/status/1917612579972669856"
|
||||
author: "Mysterious Castle"
|
||||
handle: eclectocrat
|
||||
post_id: "1917612579972669856"
|
||||
date: 2025-04-30
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- rfleury
|
||||
description: "@rfleury I'd use C more if attribute(__cleanup__) was standard and a little less cumbersome."
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1917431895786414425"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/eclectocrat/status/1917612579972669856
|
||||
- Author: Mysterious Castle (@eclectocrat)
|
||||
- Posted: 2025-04-30 16:10:41
|
||||
|
||||
## Branch
|
||||
|
||||
**1/** @eclectocrat
|
||||
|
||||
@rfleury
|
||||
|
||||
I'd use C more if attribute(__cleanup__) was standard and a little less cumbersome. C++ stack unwinding is and always has been it's killer feature.
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a]]
|
||||
+54
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: "My experience has been different."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/mikejt4/status/1917515273680347506"
|
||||
author: "Michael Tomlinson"
|
||||
handle: mikejt4
|
||||
post_id: "1917515273680347506"
|
||||
date: 2025-04-30
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- rfleury
|
||||
description: "My experience has been different."
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1917431895786414425"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/mikejt4/status/1917515273680347506
|
||||
- Author: Michael Tomlinson (@mikejt4)
|
||||
- Posted: 2025-04-30 09:44:01
|
||||
|
||||
## Branch
|
||||
|
||||
**1/** @mikejt4
|
||||
|
||||
My experience has been different. Every piece of C code I used had weird memory leaks and page faults.
|
||||
Good C++ with no naked pointers… huge codebase, dozens of developers - never one memory leaks. And performance was fantastic. Maybe not identical to hand-optimized C… but *far* easier to understand and maintain… especially for non god-like developers. We converted everything to C++, including our realtime embedded code. (Medical dev, so regulated, process driven…).
|
||||
|
||||
**2/** @rfleury
|
||||
|
||||
@mikejt4
|
||||
|
||||
Many people have written C in very poor ways, but with the correct approach, it’s (a) simpler, (b) faster, (c) easier to maintain, (d) easier to read
|
||||
|
||||
**3/** @dervish_candela
|
||||
|
||||
@rfleury @mikejt4
|
||||
|
||||
if there is so little code written 'with the correct approach', perhaps 'the correct approach' is in fact anything but easier and simpler
|
||||
|
||||
**4/** @rfleury
|
||||
|
||||
@dervish_candela @mikejt4
|
||||
|
||||
I genuinely have no idea how you think that’s a coherent point—do you think fields simply do not advance?
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a]]
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "@rfleury Also people will say this garbage and then show you the assembly in -O2."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/shwadev78/status/1917447655128719815"
|
||||
author: "Joshua"
|
||||
handle: shwadev78
|
||||
post_id: "1917447655128719815"
|
||||
date: 2025-04-30
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- rfleury
|
||||
description: "@rfleury Also people will say this garbage and then show you the assembly in -O2."
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1917431895786414425"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/shwadev78/status/1917447655128719815
|
||||
- Author: Joshua (@shwadev78)
|
||||
- Posted: 2025-04-30 05:15:20
|
||||
|
||||
## Branch
|
||||
|
||||
**1/** @shwadev78
|
||||
|
||||
@rfleury
|
||||
|
||||
Also people will say this garbage and then show you the assembly in -O2. Debug build lives matter!
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a]]
|
||||
+77
@@ -0,0 +1,77 @@
|
||||
---
|
||||
title: "@rfleury individual malloc/free is a common C practice and is the fair comparison; group allocations are not the norm in most programs especially in the hand-off ownership situations where unique_ptr would apply."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/AbstrctMachnist/status/1917754448178188666"
|
||||
author: "AbstractMachinist"
|
||||
handle: AbstrctMachnist
|
||||
post_id: "1917754448178188666"
|
||||
date: 2025-05-01
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- rfleury
|
||||
description: "@rfleury individual malloc/free is a common C practice and is the fair comparison; group allocations are not the norm in most programs especially in the hand-off ownership situations where unique_ptr would apply."
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1917431895786414425"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/AbstrctMachnist/status/1917754448178188666
|
||||
- Author: AbstractMachinist (@AbstrctMachnist)
|
||||
- Posted: 2025-05-01 01:34:25
|
||||
|
||||
## Branch
|
||||
|
||||
**1/** @AbstrctMachnist
|
||||
|
||||
@rfleury
|
||||
|
||||
individual malloc/free is a common C practice and is the fair comparison; group allocations are not the norm in most programs especially in the hand-off ownership situations where unique_ptr would apply. In this light unique_ptr is strictly superior.
|
||||
|
||||
**2/** @rfleury
|
||||
|
||||
@AbstrctMachnist
|
||||
|
||||
No, it isn’t the fair comparison, because that is not how sensible code is written.
|
||||
|
||||
**3/** @AbstrctMachnist
|
||||
|
||||
@rfleury
|
||||
|
||||
Okay, well it's a like-vs-like comparison. If used as a straightforward replacement, unique_ptr is better. I concede it's not a replacement for a careful memory strategy.
|
||||
|
||||
**4/** @rfleury
|
||||
|
||||
@AbstrctMachnist
|
||||
|
||||
But the equivalent code isn’t straightforward. It’s not *careful* to do something better. It’s both *easier and faster*. It is simply the superior way to not use them at all.
|
||||
|
||||
**5/** @AbstrctMachnist
|
||||
|
||||
@rfleury
|
||||
|
||||
Looking at the RAD Debugger as an example (which is unfair, since you can't look at my code), the diligence of passing an allocator through every function, and being constantly mindful of which pool a given string is coming from, does not seem simple, though it is impressive.
|
||||
|
||||
**6/** @rfleury
|
||||
|
||||
It isn't through every function, though. And it is not accurate to say you are "constantly mindful" about it. Layers which allocate plan for & control those allocations through a variety of strategies. Most allocations are bucketed into arenas, so the allocation occurs and is forgotten. Anyone who is passed an allocation can use the allocation, they do not have to care about where it came from.
|
||||
|
||||
**7/** @AbstrctMachnist
|
||||
|
||||
@rfleury
|
||||
|
||||
Alright, but surely this is more thought than probably even 95% of programs give to such things. Nor are most programs developed with such careful attention to layers and their individual memory strategies. And I don't think they should need to, by default.
|
||||
|
||||
**8/** @rfleury
|
||||
|
||||
@AbstrctMachnist
|
||||
|
||||
*Someone* has to build those layers, is the point. The high level code doesn't have to think about anything. I agree that at those layers, nobody should be having to think about anything other than their problem.
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a]]
|
||||
+45
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: "@rfleury Look at any large codebase and you'll see a bunch of new/delete calls."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/RokCej/status/1918077301998129432"
|
||||
author: "Rok Cej"
|
||||
handle: RokCej
|
||||
post_id: "1918077301998129432"
|
||||
date: 2025-05-01
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- rfleury
|
||||
description: "@rfleury Look at any large codebase and you'll see a bunch of new/delete calls."
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1917431895786414425"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/RokCej/status/1918077301998129432
|
||||
- Author: Rok Cej (@RokCej)
|
||||
- Posted: 2025-05-01 22:57:19
|
||||
|
||||
## Branch
|
||||
|
||||
**1/** @RokCej
|
||||
|
||||
@rfleury
|
||||
|
||||
Look at any large codebase and you'll see a bunch of new/delete calls. Replacing them with std::unique_ptr would make the code safer without adding any overhead, which was OP's point.
|
||||
|
||||
Your argument pertains to a completely different topic and reeks of pretentiousness.
|
||||
|
||||
**2/** @rfleury
|
||||
|
||||
@RokCej
|
||||
|
||||
I simply cannot take you seriously
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a]]
|
||||
+79
@@ -0,0 +1,79 @@
|
||||
---
|
||||
title: "@rfleury Do you have any example of this?"
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/slendidev/status/1917745453656940712"
|
||||
author: "Slendi"
|
||||
handle: slendidev
|
||||
post_id: "1917745453656940712"
|
||||
date: 2025-05-01
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- rfleury
|
||||
description: "@rfleury Do you have any example of this?"
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1917431895786414425"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/slendidev/status/1917745453656940712
|
||||
- Author: Slendi (@slendidev)
|
||||
- Posted: 2025-05-01 00:58:40
|
||||
|
||||
## Branch
|
||||
|
||||
**1/** @slendidev
|
||||
|
||||
@rfleury
|
||||
|
||||
Do you have any example of this?
|
||||
|
||||
**2/** @rfleury
|
||||
|
||||
@xslendix
|
||||
|
||||
Example of what?
|
||||
|
||||
**3/** @slendidev
|
||||
|
||||
@rfleury
|
||||
|
||||
Of where stripping the smart pointers and other RAII stuff leads to simpler memory management (less allocations, less computation)
|
||||
|
||||
**4/** @rfleury
|
||||
|
||||
@xslendix
|
||||
|
||||
I have written several 100K LOC that is completely public that you can go look at and compare with other approaches
|
||||
|
||||
**5/** @slendidev
|
||||
|
||||
@rfleury
|
||||
|
||||
From looking at RADDbg, most of those allocations are avoided by using an arena. How is this any different from passing in an arena to a string for example instead of using the standard allocator?
|
||||
|
||||
**6/** @rfleury
|
||||
|
||||
@xslendix
|
||||
|
||||
It’s completely flipped from the usual RAII approach. Allocated things do not manage themselves. They don’t “know” about their allocator. Everything is just data organized into large buckets. As such, there are no destructors to insert, because there is no freeing to do.
|
||||
|
||||
**7/** @slendidev
|
||||
|
||||
@rfleury
|
||||
|
||||
You can just make the free method of the allocator be empty. If the arena is block based (growing arena) then you can also absolutely use that free method to re-use memory in previous blocks.
|
||||
|
||||
**8/** @rfleury
|
||||
|
||||
@xslendix
|
||||
|
||||
There’s no point.
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a]]
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "@rfleury Well said."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/wmcoyne/status/1917753799021646262"
|
||||
author: "William M Coyne"
|
||||
handle: wmcoyne
|
||||
post_id: "1917753799021646262"
|
||||
date: 2025-05-01
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- rfleury
|
||||
description: "@rfleury Well said."
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1917431895786414425"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/wmcoyne/status/1917753799021646262
|
||||
- Author: William M Coyne (@wmcoyne)
|
||||
- Posted: 2025-05-01 01:31:50
|
||||
|
||||
## Branch
|
||||
|
||||
**1/** @wmcoyne
|
||||
|
||||
@rfleury
|
||||
|
||||
Well said. Zero-overhead in the abstract isn't the same as zero-complexity in practice. Hand-coding forces you to confront design directly, not just inherit layers of generic indirection. Sometimes simpler really is better—especially when it matches your problem more precisely.
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a]]
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
title: "To the degree this is true, it’s only in a technical sense."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/rfleury/status/1917431895786414425"
|
||||
author: "Ryan Fleury"
|
||||
handle: rfleury
|
||||
post_id: "1917431895786414425"
|
||||
date: 2025-04-30
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- rfleury
|
||||
description: "To the degree this is true, it’s only in a technical sense."
|
||||
in_reply_to: ""
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/rfleury/status/1917431895786414425
|
||||
- Author: Ryan Fleury (@rfleury)
|
||||
- Posted: 2025-04-30 04:12:42
|
||||
|
||||
## Thread
|
||||
|
||||
**1/** @rfleury
|
||||
|
||||
To the degree this is true, it’s only in a technical sense. When you actually force yourself to inline all of the extra nonsense that is implicitly happening in modern C++ codebases, it quickly becomes obvious that something is wrong, and it’s an enormously subpar solution.
|
||||
|
||||
Yes, if you had handwritten all of the heap allocations, reference counts, checks, and lifetime management by hand in regular C, then you’d just be doing exactly what std::unique_ptr is doing, and this allows them to sell it as “zero cost”.
|
||||
|
||||
The difference is that when you strip all that extra stuff away, you are in an enormously better position to design much simpler memory allocation solutions that conform much better to the reality of your problem. As a consequence, your final solution does, in fact, have dramatically fewer heap allocations, many fewer computations, and there is simply a lot less going on—it’s a much more transparent system to you.
|
||||
|
||||
Not to mention the fact that your compile times become way faster, all of your data structures are much simpler, and they’re much more easily inspected in the debugger.
|
||||
|
||||
Branches: [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-AnthonyPatch15-saw-a-casey-muratori-video-about-people-who-think]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-shwadev78-also-people-will-say-this-garbage-and-then-show]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-MoveZig4-this-isnt-such-a-strong-argument-considering]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-KirillKiriche11-i-miss-the-point-you-are-trying-to-make]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-DomWitczak-there-is-exactly-zero-pain-in-debugging-unique]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-anilcanglk12-i-bet-std-comitee-wrote-thousands-of-lines-for]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-mikejt4-my-experience-has-been-different-every-piece-of-c]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-Wouter_Bijlsma-generated-assembly-or-other-supposedly-better]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-Pps831-too-much-words-but-unique-ptr-is-really-zero-cost]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-eclectocrat-id-use-c-more-if-attribute-cleanup-was-standard]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-05-01-slendidev-do-you-have-any-example-of-this]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-05-01-wmcoyne-well-said-zero-overhead-in-the-abstract-isnt-the]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-05-01-AbstrctMachnist-individual-malloc-free-is-a-common-c-practice-and]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-05-01-RokCej-look-at-any-large-codebase-and-youll-see-a-bunch]]
|
||||
|
||||
**2/** @SubstrataVr
|
||||
|
||||
@rfleury
|
||||
|
||||
I think you may be thinking of shared_ptr, which does reference counting. unique_ptr doesn't need to.
|
||||
|
||||
**3/** @rfleury
|
||||
|
||||
@SubstrataVr
|
||||
|
||||
You’re right about the reference counts, my mistake. The other points still stand however.
|
||||
|
||||
**4/** @static_assert_0
|
||||
|
||||
@rfleury @SubstrataVr
|
||||
|
||||
In general maybe, but I don’t really see how any of this stands for unique_ptr - it literally is just a struct around a pointer with a deleted copy constructor to give you a compile error when you try to share it?
|
||||
|
||||
Now the debugger argument that this adds extra noise is valid
|
||||
|
||||
**5/** @rfleury
|
||||
|
||||
@static_assert_0 @SubstrataVr
|
||||
|
||||
I wear certainly conflating the two (I do not use these features) but the argument stands, given that the places where you actually have “owned pointers” should be extremely small. This is seen as useful when you have 1000s of these. But you shouldn’t.
|
||||
|
||||
**6/** @AbstrctMachnist
|
||||
|
||||
@rfleury @static_assert_0 @SubstrataVr
|
||||
|
||||
I think this is a perspective difference between game developers, who have natural shared memory lifetimes in the form of frames, data batches, or update ticks, and general purpose developers where it's normal to have many operations in-flight with no common enclosing lifetime.
|
||||
|
||||
**7/** @rfleury
|
||||
|
||||
@AbstrctMachnist @static_assert_0 @SubstrataVr
|
||||
|
||||
This is not true. There are lifetimes all over the place in all fields. Everyone just lumps me into “game developers”, but I don’t even work on games professionally? How does your theory account for that? Do you think group lifetimes are somehow unique to games?
|
||||
@@ -9,4 +9,5 @@ tags:
|
||||
- rfleury
|
||||
---
|
||||
|
||||
- [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a]]
|
||||
- [[archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an]]
|
||||
Reference in new issue
Block a user