5 ms·

I think the author doesn't understand what Gruber wrote here. Android uses more memory because most Android software is written to use more memory (relying on g

by jml7c5 6y ago

I think the author doesn't understand what Gruber wrote here. Android uses more memory because most Android software is written to use more memory (relying on garbage collection). It has nothing to do with the chips. If you ran Android on an M1, it wouldn't magically need less RAM. And Photoshop compiled for x86 is going to use about the same amount of memory as Photoshop compiled for Apple silicon. Sure, if you rewrote Photoshop to use garbage collection everywhere then memory consumption would increase, but that has nothing to do with the chip.

Ar-Curunir 6y ago
If your hardware enables more regular/efficient garbage collection, then it absolutely can lower memory consumption. Given that the M1 chip was designed to better support reference counting, it makes sense that doing the same for HC could lead to a benefit
socialdemocrat 6y ago
Maybe I misread, but I understood that more as Apple using ARC and that gives them a memory advantage. M1 is simply making that more efficient by doing retain-release faster. But I agree that should not change total memory usage. But I think in general you could say that Apple has focused more on optimizing their OS for memory usage than the competition may have done. Android uses Java which eats memory like crazy and I suspect C# is not that much better being a managed and garbage collected language. Not sure how much .NET stuff is used on Windows, but I suspect a lot. macOS in contrast is really dominated by Objective-C and Swift which does not use these memory hungry garbage collection schemes, nor require JIT compilation which also eats memory.
- reader_mode 6y ago
  > I suspect C# is not that much better being a managed and garbage collected language C# is better than JVM in that it has custom value types. Say you want to allocate an array of points in Java you basically have to allocate array[pointer] all pointing to tiny 8 byte objects (for eg. 32 bit float x and y coords) + the overhead of object header. If you use C# and structs it just allocates a flat array of floats with zero overhead. Not only do you pointlessly use memory, you have indirection lookup costs, potential cache misses, more objects for GC to traverse, etc. etc. JVM really sucks at this kind of stuff and so much of GUI programming is passing around small structs like that for rendering. FWIW I think they are working on some proposal to add value types to JVM but that probably won't reach Android ever.
  - jmnicolas 6y ago
    I had a C# project that was too slow and used too much RAM. I can attest that structs use less memory however IIRC they don't have methods so no GetHashCode() which made them way too slow to insert in a HashSet or Dictionary. In the end I used regular objects in a Dictionary. RAM usage was a bit higher than structs (not unbearably so) but speed improvement was massive.
    - reader_mode 6y ago
      >I can attest that structs use less memory however IIRC they don't have methods so no GetHashCode() which made them way too slow to insert in a HashSet or Dictionary You can and should implement IEquatable on a struct, especially if you plan on placing them in a hashset - the default implementation will use reflection and will be slow but it's easy to override.
      - jmnicolas 6y ago
        I just checked, apparently structs can have methods. Is it a new thing or me that was ignorant?
        reader_mode 6y ago
        You could always have methods (for as long as I can remember at least, I started using .NET in 3.0 days), you just can't inherit structs or use virtual methods because structs don't have virtual method table. You can implement interfaces however and override operators - it's very nice for implementing 3D graphics math primitives like vectors and matrices, way better than Java in this regard which was what got me into C# way back then.
    - gameswithgo 6y ago
      1. structs can have methods 2. the primary value of value types is not to use less ram (you just save a pointer, I guess times two because of GC) but the ability to avoid having to GC the things, since they are either on the stack or in contiguos chunks of memory, and to leverage cpu caches are you can iterate over contiguous data rather than hopping around in the heap. Iterating over contiguous data can be a large constant factor faster than over a collection of pointers to heap objects.

by jml7c5 6y ago

Ar-Curunir 6y ago

If your hardware enables more regular/efficient garbage collection, then it absolutely can lower memory consumption. Given that the M1 chip was designed to better support reference counting, it makes sense that doing the same for HC could lead to a benefit

socialdemocrat 6y ago

Maybe I misread, but I understood that more as Apple using ARC and that gives them a memory advantage. M1 is simply making that more efficient by doing retain-release faster. But I agree that should not change total memory usage. But I think in general you could say that Apple has focused more on optimizing their OS for memory usage than the competition may have done. Android uses Java which eats memory like crazy and I suspect C# is not that much better being a managed and garbage collected language. Not sure how much .NET stuff is used on Windows, but I suspect a lot. macOS in contrast is really dominated by Objective-C and Swift which does not use these memory hungry garbage collection schemes, nor require JIT compilation which also eats memory.

reader_mode 6y ago
> I suspect C# is not that much better being a managed and garbage collected language C# is better than JVM in that it has custom value types. Say you want to allocate an array of points in Java you basically have to allocate array[pointer] all pointing to tiny 8 byte objects (for eg. 32 bit float x and y coords) + the overhead of object header. If you use C# and structs it just allocates a flat array of floats with zero overhead. Not only do you pointlessly use memory, you have indirection lookup costs, potential cache misses, more objects for GC to traverse, etc. etc. JVM really sucks at this kind of stuff and so much of GUI programming is passing around small structs like that for rendering. FWIW I think they are working on some proposal to add value types to JVM but that probably won't reach Android ever.
- jmnicolas 6y ago
  I had a C# project that was too slow and used too much RAM. I can attest that structs use less memory however IIRC they don't have methods so no GetHashCode() which made them way too slow to insert in a HashSet or Dictionary. In the end I used regular objects in a Dictionary. RAM usage was a bit higher than structs (not unbearably so) but speed improvement was massive.
  - reader_mode 6y ago
    >I can attest that structs use less memory however IIRC they don't have methods so no GetHashCode() which made them way too slow to insert in a HashSet or Dictionary You can and should implement IEquatable on a struct, especially if you plan on placing them in a hashset - the default implementation will use reflection and will be slow but it's easy to override.
    - jmnicolas 6y ago
      I just checked, apparently structs can have methods. Is it a new thing or me that was ignorant?
      - reader_mode 6y ago
        You could always have methods (for as long as I can remember at least, I started using .NET in 3.0 days), you just can't inherit structs or use virtual methods because structs don't have virtual method table. You can implement interfaces however and override operators - it's very nice for implementing 3D graphics math primitives like vectors and matrices, way better than Java in this regard which was what got me into C# way back then.
  - gameswithgo 6y ago
    1. structs can have methods 2. the primary value of value types is not to use less ram (you just save a pointer, I guess times two because of GC) but the ability to avoid having to GC the things, since they are either on the stack or in contiguos chunks of memory, and to leverage cpu caches are you can iterate over contiguous data rather than hopping around in the heap. Iterating over contiguous data can be a large constant factor faster than over a collection of pointers to heap objects.