Hacker News new | ask | show | jobs
by victormeriqui 846 days ago
Thanks for the feedback

I do have quite a lot of shared_ptrs throughout the entire code base, that could be reduced

The main reason behind that is I wanted a lot of flexibility between the components and didn't want to end up centralising too much logic in a single one

For example: there is a resource_manager which is a shared pointer created in the game component, it's shared with the scene_renderer (it needs to use it to get the resource data), but I like to keep it also in the game component for loading new resources

of course I could have it owned by just the scene_renderer and access it from there avoiding the reference counting

but this was a design decision that I stand behind as it really helped with clearer separation between components, and the performance, well let's say that the reference counting isn't the bottleneck here as using the console for output is pretty slow

Also the moving of shared pointers is just an optimization to avoid increasing and then immediately decreasing the ref count, no UB there since its passed by value in the argument, so it gets copied before being moved :)

1 comments

> Also the moving of shared pointers is just an optimization to avoid increasing and then immediately decreasing the ref count, no UB there since its passed by value in the argument, so it gets copied before being moved

I saw that, that function is probably completely inlined by the optimiser as well so likely the move doesn't even happen there.

Just wanted to make sure since I know a lot of devs not super proficient in C++ just sticks a shared pointer on things to get around worries about ownership and don't concider the tradeoffs.

For me I concider using a unique_ptr a form of compile time check for how I'm thinking about the code. I find shared_ptr to be a smell. It's not necessarily wrong but probably needs some reasoning about.

Another note, I saw some comments somewhere about SIMD vectorisation that needs to be implemented. I would check whether the compiler isn't already doing that and if it isn't I would see about changing the code to make if possible for the optimiser to generate vectorised code.

I still haven't been at a PC so haven't been able to properly look through the code but it is nice to at least see modern C++ being used in a codebase

The compiler for sure does some vectorization for me currently, I would expect much worse performance otherwise, it's quite good at that

The SIMD idea there was more in the direction of structuring the data in a more vector friendly way, and then seeing if manually vectorized code would run better - but right now I haven't really invested much time into it :/

There's also multi threading which I wanted to add, by having the rasterizer handle triangles in parallel in different regions of the screen, but this is also just an idea which I haven't explored much yet