Live data from Hacker News

High-performance header-only container library for C++23 on x86-64

github.com

21–30 of 30 posts

Re: High-performance header-only container library for C++23 on x86-64

#21
post #8

Earlier quoted context omitted.

Which models? It's possible Opus 4.5 and GPT-5.2 are significantly less terrible with C++ than previous models. Those only came out within the past 2 months. They also have significantly more recent knowledge cut-off dates.

I'll be specific: I've been recently working with Opus 4.5 and GPT-5.2. Both have been unable to migrate a project from using ARB shaders to 3.3 and GLSL. And I don't mean migrating the shaders themselves, just changing all the boring glue code that tells the application to use GLSL and manage those instead of feeding the ARB shaders directly. They have also failed spectacularly at implementing this paper: https://ww…

Thanks, that's very specific! Sounds like that's out of reach of the current generation of models.

Will be interesting to see if models in six months time can handle this, since they clearly can't do it today.

Re: High-performance header-only container library for C++23 on x86-64

#23

Earlier quoted context omitted.

Both Codex/Claude Code are terrible with C++. Not sure why that is, but they just spit out nonsense that creates more work than it helps me. Have you tried to do any OpenGL or Vulkan work with it? Very frustrating. React and HTML, though, pretty awesome.

On the other hand, I've been using Claude Code for the past several months at work in several C++ projects. It's been fine at understanding C++. It just generates a lot of boilerplate, doesn't follow DRY, and gets persnickety with tests. I've started adding this to all of my new conversations and it seems to help: You are a principal software engineer. I report to you. Do not modify files. Do not write prose. Only pr…

Yeah, it's a decent rubber duck.

As soon as it starts trying to write actual code or generate a bunch of files it's less than helpful very quickly.

Perhaps I haven't tried enough, but I'm entirely unsold on this for anything lower level.

Re: High-performance header-only container library for C++23 on x86-64

#24
post #18

Ok, maybe someone here can clear this up for me. My understanding of B+tree's is that they are good for implementing indexes on disk because the fanout reduces disk seeks... what I don't understand is in memory b+trees... which most of the implementations I find are. What are the advantages of an in memory b+tree?

Memory also has a seek penalty. It's called a cache miss penalty. It might be easier to think of them in general as penalties for nonlocality.

Re: High-performance header-only container library for C++23 on x86-64

#26
post #23

Earlier quoted context omitted.

On the other hand, I've been using Claude Code for the past several months at work in several C++ projects. It's been fine at understanding C++. It just generates a lot of boilerplate, doesn't follow DRY, and gets persnickety with tests. I've started adding this to all of my new conversations and it seems to help: You are a principal software engineer. I report to you. Do not modify files. Do not write prose. Only pr…

Yeah, it's a decent rubber duck. As soon as it starts trying to write actual code or generate a bunch of files it's less than helpful very quickly. Perhaps I haven't tried enough, but I'm entirely unsold on this for anything lower level.

Gemini & ChatGPT have not done well at writing or analyzing OpenGL like rendering code for me, as well. And for many algorithms, it's not good at explaining them as well. And for some of the classical algorithms, like cascading shadow mapping, even articles written by people and example source code that I found is wrong or incomplete.

Learning "the old ways" is certainly valuable, because the AIs and the resources available are bad at these old ways.

Re: High-performance header-only container library for C++23 on x86-64

#27
post #8

Earlier quoted context omitted.

Which models? It's possible Opus 4.5 and GPT-5.2 are significantly less terrible with C++ than previous models. Those only came out within the past 2 months. They also have significantly more recent knowledge cut-off dates.

I'll be specific: I've been recently working with Opus 4.5 and GPT-5.2. Both have been unable to migrate a project from using ARB shaders to 3.3 and GLSL. And I don't mean migrating the shaders themselves, just changing all the boring glue code that tells the application to use GLSL and manage those instead of feeding the ARB shaders directly. They have also failed spectacularly at implementing this paper: https://ww…

It's funny, I've also been trying to use AI to implement (simpler) shadow mapping code and it has failed. I eventually formed a very solid understanding of the problem domain myself and achieved my goals with hand written code.

I might try to implement this paper, great find! I love this 2000-2010 stuff

Re: High-performance header-only container library for C++23 on x86-64

#28

Earlier quoted context omitted.

I'll be specific: I've been recently working with Opus 4.5 and GPT-5.2. Both have been unable to migrate a project from using ARB shaders to 3.3 and GLSL. And I don't mean migrating the shaders themselves, just changing all the boring glue code that tells the application to use GLSL and manage those instead of feeding the ARB shaders directly. They have also failed spectacularly at implementing this paper: https://ww…

It's funny, I've also been trying to use AI to implement (simpler) shadow mapping code and it has failed. I eventually formed a very solid understanding of the problem domain myself and achieved my goals with hand written code. I might try to implement this paper, great find! I love this 2000-2010 stuff

Oh, boy, then I have something for you:

https://artis.inrialpes.fr/Publications/2003/HLHS03a/SurveyR...

https://mrelusive.com/publications/papers/SIMD-Shadow-Volume...

https://terathon.com/gdc05_lengyel.pdf

Re: High-performance header-only container library for C++23 on x86-64

#29
post #3

> History/Motivations This project started as an exploration of using AI agents for software development. Based on experience tuning systems using Abseil's B+tree, I was curious if performance could be improved through SIMD instructions, a customized allocator, and tunable node sizes. Claude proved surprisingly adept at helping implement this quickly, and the resulting B+tree showed compelling performance improvement…

I apologize if this is common knowledge. Modern C++ coding agents need to have a deep semantic understanding of the external libraries and header files. A simple RAG on the code base is not enough. For example, GitHub Copilot for VS Code and Visual Studio uses IDE language services like IntelliSense. To that extent, using a proper C++ IDE rather than a plain editor will improve the quality of suggested code. For example, if you're using VS Code, make sure the C/C++ Extension Pack is installed.

Re: High-performance header-only container library for C++23 on x86-64

#30

Earlier quoted context omitted.

It's funny, I've also been trying to use AI to implement (simpler) shadow mapping code and it has failed. I eventually formed a very solid understanding of the problem domain myself and achieved my goals with hand written code. I might try to implement this paper, great find! I love this 2000-2010 stuff

Oh, boy, then I have something for you: https://artis.inrialpes.fr/Publications/2003/HLHS03a/SurveyR... https://mrelusive.com/publications/papers/SIMD-Shadow-Volume... https://terathon.com/gdc05_lengyel.pdf

Perfect. Now I can continue to be confused! Beginner mindset!
Post reply on HN