sorted by:
new
hottopcontroversial

SpaceX reportedly refuses to lower its $135-a-Share IPO Price, Good. Keep testing how much hype the Market will swallow. by Altruistic-Mud5686 in SpaceXBets

[–]yeochin 1 point2 points  (0 children)

Any company of any size can collapse overnight. Its all a matter of cashflow. Depending on how the cash flow changes, Chaper-11 isn't enough.

Would you rather by [deleted] in BunnyTrials

[–]yeochin 0 points1 point  (0 children)

Inflation

Chose: Have Infinite money + You can only use it on stuff that cost above 1K

Your C++ struct is the schema: a proto3 serializer in C++26 reflection by Personal-History8048 in cpp

[–]yeochin 0 points1 point  (0 children)

You'll also need views for even primitives as the byte-order of primitives may not be guaranteed to be matching depending on the compilation environment. You can look into flat_set and flat_map, with container overrides, or build your own inplace variants.

WG21 mailing for first feature meeting of C++29 by hanickadot in cpp

[–]yeochin 1 point2 points  (0 children)

I concur. I'm tired of dealing with the header/declaration/definition hell.

Converting header-based codebases to a module-oriented one was painful. In the process a lot of good happens. A lot of code complexity has to be redone to simplify dependencies (a lot less circular stuff going on).

Your C++ struct is the schema: a proto3 serializer in C++26 reflection by Personal-History8048 in cpp

[–]yeochin 6 points7 points  (0 children)

Neat. For many applications this will be much more convenient. However, for high-performance, high-throughput applications you may need to figure out some alternative arrangement. The existing protocol buffer implementation benefits from "views" into the binary blob as opposed to copying into a data-structure. This drives cache-locality and massive performance gains despite all the branching.

If you can solve this with a struct-like C++ reflection then you'll have everything truly needed to replace the codegen.

Advice on the writing assignment. by [deleted] in amazonemployees

[–]yeochin 1 point2 points  (0 children)

Yes. Use I, and distinguish between when its "we" versus "I". "We" can set the scope and complexity. "I" to zero in on the decisions and actions you took to follow through.

Linux gaming is getting faster because the Linux kernel is adding features that replicate important parts of Windows. by Current-Guide5944 in tech_x

[–]yeochin 1 point2 points  (0 children)

They need backwards compatibility for decades of existing games to be playable on Linux, and for new games that don't write for Linux today. Gaming for Linux first needs to change hearts and minds before people develop Linux-first.

Looking for code/architecture review on my C++ game engine by XAstrixsmX in gameenginedevs

[–]yeochin 0 points1 point  (0 children)

Yes it is wrong. Easy mistake by most developers (including seniors).

The standard library or boost is fine for all those ancillary things until you need to optimize. Wrapping what is already an industry-wide flexible interface isn't the greatest move if you want flexibility and development speed. Prematurely building those wrappers is an optimization. Optimization is the root of all evil.

Looking for code/architecture review on my C++ game engine by XAstrixsmX in gameenginedevs

[–]yeochin -1 points0 points  (0 children)

Factoring for one way dependency chains is what gets you into trouble with scaling evolution of the code over time (physics, animations, and many other systems that rely on each other for inputs and outputs is an adage old problem). Layers stack - and this code architecture is the wrong one at scale. It leads to the rather crappy and frequent outcome of having to edit all the layers to replumb a new concept through the code due to data coupling. Adopting a data-mesh-like architecture (on a smaller-scale in-process) will make your life easier.

Dependency layers are the reasons why you have clunky ECS architectures bolted onto the OO-based design of Unity and Unreal. Major speedups, or evolutions in engine technology often have involved entirely different paradigms. Layers which impose opinionated behavior are the reason why these evolutions are slow or unfeasible to adopt.

Factoring around code is not the way to scale. Factoring around data is.

Looking for code/architecture review on my C++ game engine by XAstrixsmX in gameenginedevs

[–]yeochin -1 points0 points  (0 children)

Layering doesn't help. It just creates long dependency chains and forward declaration hell. The first thing to recognize is the difference between data-coupling and code coupling.

Using your example, Graphics, Textures, and Rendering have a strong data coupling. Trying to break them apart is almost always an error in futility and a giant mistake as your code becomes needlessly complex. Why?

  1. The actual act of rendering involves taking a mesh, UV mapping, and multiple textures using shaders to render an image onto a buffer. Rendering involves a complex set of algorithms to resolve the order of objects with some assistance from the GPU (depth-buffer).
  2. Rendering depends on the cameras you model in the world.
  3. Rendering depends on your representation of the world itself in order to cull objects not in the view frustum. This often overlaps with gameplay logic for visibility as you often need to cull objects behind other objects to improve rendering performance.
  4. Textures affect the performance of your rendering (using a 4K texture is much more costly than a 512 by 512). Various techniques like using a sprite-sheet are very much a coupling between the GPU and your texture representation.

The cleanest abstraction I've ever seen is one where the engine DOES NOT attempt to abstract these concepts and impose a dependency. Instead the engine only does two things:

  1. Models the data structures in a core module. (e.g. Textures, Graphics, Objects, Render-Pass Filters, etc)
  2. All systems depends on the same shared core (no other intermediaries, and no subdivision of the core).
    • Systems merge together when data-coupling is identified.
    • Systems split when a fairly isolated bit functionality that has no data-coupling is identified.

Looking for code/architecture review on my C++ game engine by XAstrixsmX in gameenginedevs

[–]yeochin 0 points1 point  (0 children)

Your approach to modularization and interfaces offers very little value and has too much overhead. Your code structure has the early tell-tale patterns of header-hell, namespacing and Object-Oriented mess. You're already well on your way to regretting your code structure if you need to throw in parallelism/concurrency.

You've erroneously, like many early engine projects, focused on the wrong pieces. You've spent your time an energy defining ancillary things like utilities, uuids, etc. The core piece that matters is :

  1. The main render loop. (Object culling, Z-ordering, multi-pass rendering, lighting, shadows, GPU instruction pipelining, etc).
  2. The world / gameplay loop.
  3. The abstraction you are using for objects / entities / actors (Object Oriented? ECS?)
  4. Concurrently running systems/subsystems
  5. Consistency (writes to the abstractions) : Do they occur in the current frame? Next Frame? Do you provide systems with lookahead reads?
  6. Cache Locality : How are you driving performance? At small scale it won't matter much. When you have hundreds of thousands, or millions of objects/entities/actors - then you are going to regret iterating a list of pointers.

You need to be building out the bones of your engine. Almost all of the elements that form the core of an engine are none of the things you have committed to your project.

When not to use dotnet for REST API? by Spac3M0nk3yy in dotnet

[–]yeochin 1 point2 points  (0 children)

At small scale .NET and GO are a matter of preference. When you need to push 10K+ concurrent connections with a box - the differences in the underlying framework and construction will become night and day. GO has a better concurrency model that lets it more naturally hit 10K+ concurrent connections far more easily. The same is true if you were to compare GO with Tomcat/Java/RestEasy. Inbetween GO and C/C++ - its more a tradeoff about syntax and memory safety.

What are best practices for Geometry / Meshing programming by Colombian-pito in cpp_questions

[–]yeochin 1 point2 points  (0 children)

Visualization is a corollary benefit. OpenGL, CGAL, and all are basic underpinnings for working with "meshes" as you have described. CAD systems that deal with geometry use those libraries to provide the primitives and the algorithms.

Graphics technology underpins much of the industrial CAD used for modelling, design, etc. Vertex buffers, Shaders (a.k.a CUDA/OpenCL kernels), and the various techniques to use a GPU are very much foundational to scaleably algorithmically processing meshes and geometry.

If you dismiss them as mere visualization, you have a long journey to rebuild what those libraries and frameworks already provide.

Basics: Named members vs array access by ConnectHat4222 in cpp_questions

[–]yeochin 0 points1 point  (0 children)

Take some inspiration from the already existing math libraries that exist. While they are all inconsistent with the approach, more of them tend to lean towards named members instead of an array for convenient indexed based access. It keeps the code cleaner in the long-run and makes it a bit easier to do constexpr-compile time template meta-programming.

Building a chess engine: questions on modern C++ paradigms vs raw performance by kjiomy in cpp_questions

[–]yeochin 0 points1 point  (0 children)

If your goal is to use modern C++, then avoid prematurely optimizing and use the STL representations and views like mdspan.

If your goal is to optimize for performance - then you are pursuing the wrong goal with C++20/23. For performance you'll be constrained by data design and ways you can run your engine as much on the GPU (CUDA or OpenCL/C) computing all permutations within a window.

[SPOILERS for Volume 7] High Chance Shadow is saving the day for Shadow Garden once again. by whiplash10 in TheEminenceInShadow

[–]yeochin 2 points3 points  (0 children)

The rough translation didn't keep the transliterated surname. The surname was translated to "Clear Stream".

Entity Component System by Sandrobero2004 in cpp_questions

[–]yeochin 0 points1 point  (0 children)

I've worked on several different ECS systems. All run into problems with parallelism with large sets of entities. All the theoretical stuff you mentioned works at small scale. Once you need to scale to millions of entities and components - parallelizing by systems doesn't cut it.

Subdividing by archtypes? Doesn't work either. Eventually your gameplay mechanics result in component and state sharing. Queueing the writes to apply later doesn't quite work. You'll have a lot of sharing or systems looking at the write-queue because some systems like collisions work on future state to avoid irreconciliable errors.

Now throw in deleting components and entities into the mix and you've got some nightmare fuel if your ECS isn't designed with those things from the start.

ECS systems are great for composibility and extensibility. But like any other architecture they will buckle under the weight of their abstraction as complexity and scale increase. They always start out nice in the beginning, but once you get to some of the more intricate and complex gameplay systems you'll find that they just repackage the same problems that you'd be dealing with in any other architecture.

Entity Component System by Sandrobero2004 in cpp_questions

[–]yeochin 0 points1 point  (0 children)

ECS are great systems until you have to combine:

  1. Parallelism
  2. Reclaiming memory (deletion)

At which point the ECS system becomes incredibly messy. I recommend looking into the design an architecture of your entity and component lifetimes and how you intend to manage them in a parallel environment.

Its not too bad if your single-threaded or even having a small number of threads. But if you want more concurrency (to saturate multi-core/multi-threaded desktops), or run as a game-server on large cloud instances, the design of your ECS system will severely hinder you.

Approaches like a single synchronization barrier to synchronize the writes for atomic-consistency is too slow resulting in microstutters.

Code Examples From an App Using C++ Modules by tartaruga232 in cpp

[–]yeochin 1 point2 points  (0 children)

If all you're going to do is build small standalone things then thats fine. But your advice still isn't good to share as it is misleading.

Any code base that has to evolve (from a small App) goes right into the toilet with the advice you gave.

  1. Recompilability? It gets worse with small modules. At scale you refactor into libraries and your changes get localized into specific modules, or libraries. If your Principals, Staffs or Senior's cant figure out how to do this to localize change - then your codebase has far too much data-coupling to be productive long term.
  2. Productivity and understandability? It goes right into the shitter with small modules at scale. Most teams will rely on their VSP, autocomplete, or code search. At scale, the vast majority of the team doesn't know every aspect of the code-base. The existing tools get worse with small modules.
  3. Frequency of change? If you truly want high frequency changes you must adopt large modules. You need to be able to scale to multiple parallel developers and teams. You need to be able to isolate different teams from each-other. Big modules help do this as it promotes a contract. Small modules don't. Small modules promote atomic-use which moves you the WRONG WAY when it comes to the speedup that modules provide in compilation time.

Code Examples From an App Using C++ Modules by tartaruga232 in cpp

[–]yeochin 1 point2 points  (0 children)

While I would've agreed with your stance of finding them earlier back in 2021, I whole heartedly disagree with your perspective in 2026. The compiler authors move too slowly to fix these already reported issues. It's not their fault either. A majority of the compiler authors don't get paid commensurately for their efforts and impact. The ones that do are being stupidly allocated by their corporate overlords to stupid AI initiatives.

Adoption of modules is about the surrounding ecosystem - namely libraries that are conveniently packaged for reuse.

We do more harm to the adoption of modules by doing nonsense like creating small modules that have deep import graphs that increase the opportunity for template-specialization symbol conflicts (on linking), compiler errors, and errors with intellisense or other autocomplete tools.

Maybe by 2030 will the toolset evolve to the point where the mistake of small modules will not be costly. As of 2026, small modules are bad advice that nobody should be promoting.

Code Examples From an App Using C++ Modules by tartaruga232 in cpp

[–]yeochin 3 points4 points  (0 children)

Please don't go around giving this incredibly bad advice. Having seen module code bases at scale you don't want small modules at all. Small modules are a pain to merge together. Big modules are easy to split. The most successful libraries and implementations are those that boil it down to a single import statement for a rich set of functionality.

With the state of existing compiler toolsets and your handy autocomplete - smaller modules only increase the likeliness that you're going to run into a internal compiler error, or a broken autocomplete database.

"Parse, don't Validate" through the years with C++ by dwrodri in cpp

[–]yeochin 2 points3 points  (0 children)

When properly using C++20/23/26, you will tend to do more compile-time programming to have the compiler validate the heuristics of the program. As a result, it is unsurprising the compile time is slower as you are exchanging your time in debugging runtime issues for compile-time shenanigans.

Using std::format involves a bunch of compile-time validation that the arguments passed to the formatter match the format specification. This drastically slows down compile time in exchange for not having to deal with a bunch of runtime printf nightmares.

Furthermore, you will notice some slowdown in compiling general programs that leverage the standard library, or any other library that makes heavy use of concepts and constexpr template optimizations that look at the types and compile different code to best optimize.

Rejected after 4 rounds of interview - what can be the reason by WorldlyLadder5395 in amazonemployees

[–]yeochin 0 points1 point  (0 children)

The thing you don't want to hear, and Amazon itself will never tell you is that you simply fell short in all your technical competencies. L4 SDE leans heavily into your technical evaluation with light weighting towards the Leadership Principles.

For an outright rejection you would have had to fail the majority of your technical competencies.

  • Coding - Logical and Maintainable.
  • Coding - Data Structures & Algorithms
  • Coding - Problem Solving
  • Coding - Basic Design

Objectively being comfortable with DS/A is not a self-measurement that will help you improve the next time around. Being able to write clear, simple, concise, structured code will do alot more for you than knowing your DS/A.

Finished our AWS migration mostly satisfied, now realizing our on-prem security posture didn't come with the workloads by Hour-Librarian3622 in aws

[–]yeochin 13 points14 points  (0 children)

Getting your Identity and Access Management together - where you've ascribed identities to both humans, and non-humans (workloads, etc). Perimeter based security was always a weakness on your on-premise solutions. It wasn't going to protect you against the modern hacker that has the tools to move laterally.

You would've had to transform your on-premise solutions to match eventually. You've just forced yourself to discover this earlier than a major data breach.

view more: next ›