3 ms·

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 a

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
  > And you would probably want to focus on parallelism, where C++ again is not the best. Here again, this is wrong. 99% of highly scalable parallel code that run on supercomputers is C++ or Fortran. And there is reasons to that, if you want parallelism, you want generally performance. If you want performance you want control on NUMA, SIMD, cache locality, etc... and C++ gives you that. Not Java.
  - pjmlp 8y ago
    Yet Julia and Chapel are winning hearts of HPC researchers. Java is not the only language with GC, there are others which offer control over NUMA, SIMD, cache locality, like .NET Native with C# 7/8, or D as two possible examples.
    - gmueckl 8y ago
      But the GC is frowned upon a lot in the D community. A lot of D programmers try to make everything they write @nogc.
      - pjmlp 8y ago
        A GC in a systems programming language is there as a productivity and safety mechanism, by no means as the only way of doing 100% of memory allocations. A vocal sub-community of D programmers argue for @nogc due to GC phobia, as ex-C++ devs, and a GC implementation found lacking. A situation that might improve with the recently released GC pluggable API and a new precise tracing GC. Many devs that prototype their apps in D without doing premature memory optimizations, end up realizing that for their use case it actually good enough.

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
> And you would probably want to focus on parallelism, where C++ again is not the best. Here again, this is wrong. 99% of highly scalable parallel code that run on supercomputers is C++ or Fortran. And there is reasons to that, if you want parallelism, you want generally performance. If you want performance you want control on NUMA, SIMD, cache locality, etc... and C++ gives you that. Not Java.
- pjmlp 8y ago
  Yet Julia and Chapel are winning hearts of HPC researchers. Java is not the only language with GC, there are others which offer control over NUMA, SIMD, cache locality, like .NET Native with C# 7/8, or D as two possible examples.
  - gmueckl 8y ago
    But the GC is frowned upon a lot in the D community. A lot of D programmers try to make everything they write @nogc.
    - pjmlp 8y ago
      A GC in a systems programming language is there as a productivity and safety mechanism, by no means as the only way of doing 100% of memory allocations. A vocal sub-community of D programmers argue for @nogc due to GC phobia, as ex-C++ devs, and a GC implementation found lacking. A situation that might improve with the recently released GC pluggable API and a new precise tracing GC. Many devs that prototype their apps in D without doing premature memory optimizations, end up realizing that for their use case it actually good enough.