4 ms·

They said "has support for", not "is". This is a natural consequence of having value types (structs). You can even change the bit packing and other layout prop

They said "has support for", not "is". This is a natural consequence of having value types (structs). You can even change the bit packing and other layout properties of structs.

bitmapbrother 10y ago
Are you replying to the proper comment? In any case, he stated that an Android C# app would be more performant than an app coded in Java without supplying any metrics to prove his point. >This is a natural consequence of having value types (structs). You can even change the bit packing and other layout properties of structs. And yet the JVM still beats the CLR in performance.
- int_19h 10y ago
  > And yet the JVM still beats the CLR in performance. On mobile memory-constrained devices? Can you share a benchmark demonstrating that?
  - bitmapbrother 10y ago
    The JVM reference inferred non mobile.
    - pjmlp 10y ago
      There are lots of J2ME in use, in spite of Android.
      - int_19h 10y ago
        Yes, and it has always had horrible perf, especially when it came to memory. Standard techniques to reduce memory pressure included never ever instantiating your classes. So basically everything is a static method, and the only data types you can use are primitives, since Java doesn't have structs (exactly the problem that this thread pointed out at the beginning). So people would instead preallocate global arrays of primitives, and referenced their elements by index, if they needed to pass something like a record or an object around.
        pjmlp 10y ago
        > exactly the problem that this thread pointed out at the beginning Sure, hence why I started it. :)
- pjmlp 10y ago
  > And yet the JVM still beats the CLR in performance. Which CLR and which JVM? Languages are not implementations, I remember when junior Assembly coders could easily write code better than any C compiler, and look how C is regarded nowadays! As for the CLR code, if you know about compilers and watched Channel 9 and MS blogs, than you would know that Microsoft only made the CLR good enough. Only now they are sharing the backend with Visual C++.
- xorxornop 10y ago
  I'm not actually sure which comment I'd intended to reply to anymore (wrote it quickly on a lunch break!) - but, anyway: I'd agree the JVM is a bit faster than the CLR currently, but this is arguably because the CLR is more heavily tuned towards startup time (the reduction of), rather than throughput. They've invested more heavily into AOT compilation support (also in service of this goal) and compiler-as-a-service tech (Roslyn) rather than performance... perhaps this might change? Certainly the community additions to the CLR and the larger ecosystem eg ASP.NET Core have produced some notable performance improvements. Also I'd say the CLR has more potential insofar as performance due to its design than the JVM does, but the JVM has received more attention in this area historically, so it's 'winning' currently despite this.

They said "has support for", not "is". This is a natural consequence of having value types (structs). You can even change the bit packing and other layout properties of structs.

bitmapbrother 10y ago

Are you replying to the proper comment? In any case, he stated that an Android C# app would be more performant than an app coded in Java without supplying any metrics to prove his point. >This is a natural consequence of having value types (structs). You can even change the bit packing and other layout properties of structs. And yet the JVM still beats the CLR in performance.

int_19h 10y ago
> And yet the JVM still beats the CLR in performance. On mobile memory-constrained devices? Can you share a benchmark demonstrating that?
- bitmapbrother 10y ago
  The JVM reference inferred non mobile.
  - pjmlp 10y ago
    There are lots of J2ME in use, in spite of Android.
    - int_19h 10y ago
      Yes, and it has always had horrible perf, especially when it came to memory. Standard techniques to reduce memory pressure included never ever instantiating your classes. So basically everything is a static method, and the only data types you can use are primitives, since Java doesn't have structs (exactly the problem that this thread pointed out at the beginning). So people would instead preallocate global arrays of primitives, and referenced their elements by index, if they needed to pass something like a record or an object around.
      - pjmlp 10y ago
        > exactly the problem that this thread pointed out at the beginning Sure, hence why I started it. :)
pjmlp 10y ago
> And yet the JVM still beats the CLR in performance. Which CLR and which JVM? Languages are not implementations, I remember when junior Assembly coders could easily write code better than any C compiler, and look how C is regarded nowadays! As for the CLR code, if you know about compilers and watched Channel 9 and MS blogs, than you would know that Microsoft only made the CLR good enough. Only now they are sharing the backend with Visual C++.
xorxornop 10y ago
I'm not actually sure which comment I'd intended to reply to anymore (wrote it quickly on a lunch break!) - but, anyway: I'd agree the JVM is a bit faster than the CLR currently, but this is arguably because the CLR is more heavily tuned towards startup time (the reduction of), rather than throughput. They've invested more heavily into AOT compilation support (also in service of this goal) and compiler-as-a-service tech (Roslyn) rather than performance... perhaps this might change? Certainly the community additions to the CLR and the larger ecosystem eg ASP.NET Core have produced some notable performance improvements. Also I'd say the CLR has more potential insofar as performance due to its design than the JVM does, but the JVM has received more attention in this area historically, so it's 'winning' currently despite this.