4 ms·

> Most programs don't need C++ performance. Java is usually within factor of two and usually fast enough. Meshing software is a typical program where you need

• fulafel 8y ago
  The billion vertex objects might be a nice torture test benchmark for a gc or malloc implementation, but fortunately things aren't so grim in the real world: Performant mesh manipulation code as a rule deals with largish float arrays (or other similar contiguous layouts, like AoS or SoA or indexed versions thereof). So there are no per-vertex objects to malloc/free or to track in GC. In some algorithms, other data structures such as trees, may be used used as intermediate formats, but there too the options to use malloc/gc allocated nodes vs alternatives is similar in a GC'd vs a non-GC'd language. In general, good GC's often outperform malloc/free. Because GC's are amenable to parallelization in the background, and because malloc/free don't enjoy the bump-allocator style happy case that is used in generational GC's nursery objects.
  • gmueckl 8y ago
    I never met a GC that can deal with millions of allocations per second while having several millions of objects in the young generations. Some mesh processing algorithms have a tendency to get you there very quickly if you do not employ custom allocators. At this point you already defeated the GC provided by the language.
    • fulafel 8y ago
      You would have to be dealing with a very large number of meshes at once, if you were churning through millions of vertex and uv arrays per second. I can't say what you should use in this scneario. But this is a pretty niche scenario! And you would probably want to focus on parallelism, where C++ again is not the best.
      • gmueckl 8y ago
        No, I am talking about operations that alter the topology of single large meshes. Just creating a single tesselated sphere with full topological information gets you there easily.
        • fulafel 8y ago
          Ah, we may be talking past each other then. So I reiterate my point from upthread: > Performant mesh manipulation code as a rule deals with largish float arrays (or other similar contiguous layouts, like AoS or SoA or indexed versions thereof). So there are no per-vertex objects to malloc/free or to track in GC.
          • gmueckl 8y ago
            Thia is true only if you have the foresight to write custom allocators. Unless you limit possible mesh topologies, you must deal with many tiny arrays for each vertex, edge and face and their lengths are not uniform.
            • fulafel 8y ago
              Yes, depending on what you mean by custom allocator... but this is the same in C++ too, right? To store custom vertex / face attributes, you can use a variety of sparse techniques to save memory from sitting unused in attribute arrays. Basically you want an interface of get_attribute(type, vertex_id). This sparse matrix, trie, or whatever can be backed by int or float array storage instead of many many tiny malloc'd/gc'd objets.
              • gmueckl 8y ago
                Yes, these backing constructs essentially become special case memory managers for the problem domain. You may call then by different names, but the essential behaviour is the same.
      • adev_ 8y ago
  • 0815test 8y ago
    > and because malloc/free don't enjoy the bump-allocator style happy case that is used in generational GC's nursery objects. Performance-optimized use of malloc and free involves using custom suballocators (often called simply "allocators" within user code) which are tailored to the "happy cases" that you know about in your code. A "nursery" of objects that can be bump-allocated and then freed in a single operation is known in this context as an arena/region, and you absolutely can exploit this pattern as part of using malloc/free.
• gmueckl 8y ago
  I have to second this. I tried to write a 3d modelling tool in Java. I got decent, but not stellar performance only once I consciously started to fight the GC in my code. I converted that code to C++ and recently added a custom allocator to improve performance even further. The result is now functionally equivalent, but about 5 times faster.