7 ms·

Excellent. Genuine innovation on a platform many had feared was abandoned. My only regret is the confusing x86/x64 message. Many will interpret perf improvemen

Excellent. Genuine innovation on a platform many had feared was abandoned. My only regret is the confusing x86/x64 message. Many will interpret perf improvements being due to the 64 bitness of new compiler

malkia 13y ago
The other one is that it's available only on 8.1 - I wish 7 was supported too.
Locke1689 13y ago
The compiler is not 64 bit. :)
- freikev 13y ago
  Which compiler are you talking about? The JIT compiler is 64 bit, the C++ x64 targeting compiler is available as both 32 & 64 bit. Roslyn is 32 bit because, well, the x64 JIT is dog slow :-)
  - Locke1689 13y ago
    I was referring to C#, but I may have misunderstood the parent. The C# compiler isn't 64, but unfortunately it's not because of the JIT.
freikev 13y ago
Can you expand on what you mean by "confusing x86/x64 message"? I'd love to help clear it up. Are you saying that people will believe that the reason the JIT is so much faster is because it's 64 bits? That's the exact opposite of reality: 64 bit programs tend to be slower, because they have to manipulate more data (all pointers take twice as much space, the Win64 ABI requires a minimum of 48 bytes of stack per non-leaf function, etc...)
- curiousDog 13y ago
  Do all 64-bit programs tend to be slower all the time though? I'd think it would be faster because you're processing more data per clock cycle. Or is that the x64 JIT hasn't been optimized to take advantage of the latest gen of 64-bit processors (I heard stuff about not making use of the latest Math.Pow a while ago)?
  - freikev 13y ago
    Programs that are pointer-heavy tend to be a little slower. There's really not that much 64-bit arithmetic going on in the average application, so the more data per clock cycle only helps in a particular class of apps. Cryptography tends to do significantly better, for that exact reason. You do seem to be conflating code quality with compiler throughput, though. I'll try to clarify in much more detail in a CLR Codegen blog post soon.
  - groovy2shoes 13y ago
    > I'd think it would be faster because you're processing more data per clock cycle. This is only true if you happen to be dealing with integers larger than 32 bits (rarely in most of today's code). The real performance benefit of x64 has more to do with a larger number of general-purpose registers. More registers allow (but don't guarantee) programs to spend less time accessing main memory, thus gaining some speed.
    - curiousDog 13y ago
      Yes, I knew about the registers. I guess I overestimated the number of applications that involve large number computations.
      - groovy2shoes 13y ago
        Or perhaps I underestimated them...
- MichaelGG 13y ago
  Why can't the CLR come up with their own "X32" target? IIRC, they made the default for projects in VS to be 32-bit explicitly because of better codegen and lower overhead. If an app is OK with 4GB of RAM, why not let the process run in 64-bit mode, but use 32-bit pointers? Also, why should the Win64 ABI constrain everything? Certainly it'd only be needed around the edges, but for .NET code calling other .NET code, you're free to do interesting things. (Like pass a GUID or tuple in a single register if it'd help.)
taspeotis 13y ago
> Genuine innovation on a platform many had feared was abandoned. Are you equating .NET in general with Silverlight? Honest question.
- MichaelGG 13y ago
  No, but the way MS came out with WinRT and excluded existing .NET code from executing on it certainly didn't reassure anyone.
  - taspeotis 13y ago
    Uh... WinRT excluded all existing third-party code from executing on it. EDIT: asveikau has rightly pointed out I have confused two matters.
    - asveikau 13y ago
      Surely you would not confuse WinRT, the API, with Windows RT, the ARM tablet product. Why, these names are totally unambiguous! (Microsoft is not great at naming products.)
      - Locke1689 13y ago
        I agree :(
  - jmcqk6 13y ago
    WinRT was definitely a screw-up, but at this point I don't see it really effecting developers that much. WinRT has pretty much failed as a platform. At this point, is it even worth developer time to deliver an app to that platform? If you're talking about apps in the windows app store (so-called metro-style apps or whatever the current name is), then you're right that it meant throwing out a lot of code, but it's not true that all existing .NET code was excluded. It took some rejiggering. But once again, that's only if you want to deliver via the app store.
    - 13y ago

malkia 13y ago

The other one is that it's available only on 8.1 - I wish 7 was supported too.

Locke1689 13y ago

The compiler is not 64 bit. :)

freikev 13y ago
Which compiler are you talking about? The JIT compiler is 64 bit, the C++ x64 targeting compiler is available as both 32 & 64 bit. Roslyn is 32 bit because, well, the x64 JIT is dog slow :-)
- Locke1689 13y ago
  I was referring to C#, but I may have misunderstood the parent. The C# compiler isn't 64, but unfortunately it's not because of the JIT.

freikev 13y ago

Can you expand on what you mean by "confusing x86/x64 message"? I'd love to help clear it up. Are you saying that people will believe that the reason the JIT is so much faster is because it's 64 bits? That's the exact opposite of reality: 64 bit programs tend to be slower, because they have to manipulate more data (all pointers take twice as much space, the Win64 ABI requires a minimum of 48 bytes of stack per non-leaf function, etc...)

curiousDog 13y ago
Do all 64-bit programs tend to be slower all the time though? I'd think it would be faster because you're processing more data per clock cycle. Or is that the x64 JIT hasn't been optimized to take advantage of the latest gen of 64-bit processors (I heard stuff about not making use of the latest Math.Pow a while ago)?
- freikev 13y ago
  Programs that are pointer-heavy tend to be a little slower. There's really not that much 64-bit arithmetic going on in the average application, so the more data per clock cycle only helps in a particular class of apps. Cryptography tends to do significantly better, for that exact reason. You do seem to be conflating code quality with compiler throughput, though. I'll try to clarify in much more detail in a CLR Codegen blog post soon.
- groovy2shoes 13y ago
  > I'd think it would be faster because you're processing more data per clock cycle. This is only true if you happen to be dealing with integers larger than 32 bits (rarely in most of today's code). The real performance benefit of x64 has more to do with a larger number of general-purpose registers. More registers allow (but don't guarantee) programs to spend less time accessing main memory, thus gaining some speed.
  - curiousDog 13y ago
    Yes, I knew about the registers. I guess I overestimated the number of applications that involve large number computations.
    - groovy2shoes 13y ago
      Or perhaps I underestimated them...
MichaelGG 13y ago
Why can't the CLR come up with their own "X32" target? IIRC, they made the default for projects in VS to be 32-bit explicitly because of better codegen and lower overhead. If an app is OK with 4GB of RAM, why not let the process run in 64-bit mode, but use 32-bit pointers? Also, why should the Win64 ABI constrain everything? Certainly it'd only be needed around the edges, but for .NET code calling other .NET code, you're free to do interesting things. (Like pass a GUID or tuple in a single register if it'd help.)

taspeotis 13y ago

> Genuine innovation on a platform many had feared was abandoned. Are you equating .NET in general with Silverlight? Honest question.

MichaelGG 13y ago
No, but the way MS came out with WinRT and excluded existing .NET code from executing on it certainly didn't reassure anyone.
- taspeotis 13y ago
  Uh... WinRT excluded all existing third-party code from executing on it. EDIT: asveikau has rightly pointed out I have confused two matters.
  - asveikau 13y ago
    Surely you would not confuse WinRT, the API, with Windows RT, the ARM tablet product. Why, these names are totally unambiguous! (Microsoft is not great at naming products.)
    - Locke1689 13y ago
      I agree :(
- jmcqk6 13y ago
  WinRT was definitely a screw-up, but at this point I don't see it really effecting developers that much. WinRT has pretty much failed as a platform. At this point, is it even worth developer time to deliver an app to that platform? If you're talking about apps in the windows app store (so-called metro-style apps or whatever the current name is), then you're right that it meant throwing out a lot of code, but it's not true that all existing .NET code was excluded. It took some rejiggering. But once again, that's only if you want to deliver via the app store.
  - 13y ago