The problem with being second

re: The problem with being second

Jim Arnold — Tue, 07 Sep 2004 17:19:00 GMT

Er, what's the point in having a portable runtime if I have to make my high-level code aware of the processor I'm running on? Are you saying that the behaviour of my code varies between x86 and AMD64?

re: The problem with being second

Grant — Tue, 07 Sep 2004 17:24:00 GMT

No you shouldn't have to be aware of the processor you're running on, but yes, there will be differences. And specifically if you're writing multi-threaded code and you don't follow the spec for all the things the runtime is allowed to do (but may not actually be doing right now on x86 version 1.0 or 1.1) you will likely get bitten.

My point is that that x86 is allowed to do the same thing, but they don't (right now). It is tough being second because people find these differences and naturally assume it's a bug in the new stuff, rather than their own mis-use or misunderstanding.
--Grant

re: The problem with being second

Joe — Tue, 07 Sep 2004 17:30:00 GMT

I agree, hats off to the Mono team, but suspect that over time it will be difficult to keep up with the evolution of the .NET Framework. And a minimal CLR won't be enough for many users - .NET 2.0 contains lots of stuff which will quickly become "must have".

I remember people taking their hats off to IBM when OS/2 was a "better Windows than Windows". But IBM couldn't keep up with the evolution to Win32.

I already know of one subtle difference which could mean an app that runs in Mono might break in MS .NET.

re: The problem with being second

Barry Dorrans — Tue, 07 Sep 2004 17:33:00 GMT

What about the spot CLR, or the compact CLR?

Aren't you fourth? :)

re: The problem with being second

Grant — Tue, 07 Sep 2004 17:39:00 GMT

I've never heard of the spot CLR.

In the case of the compact CLR, they weren't trying to duplicate the desktop CLR, but simply mimic it. Thus certain differences were expected. Also due to device constraints the compact CLR is unlikely to perform more optimizations than the desktop CLR.

People expect the desktop CLR and compact CLR to be slightly different. People won't expect the CLR to be different between their server running on a Xeon and their server running on an Opteron.

Yes, technically you are right about us not being the second JIT (there was even the Rotor JITs). But we are the second desktop JIT built by Microsoft that was expected to perform as good as the existing JIT, but on a new architecture.
--Grant

re: The problem with being second

Barry Dorrans — Tue, 07 Sep 2004 17:49:00 GMT

Ah, the Spot CLR is the never confirmed but widely rumoured CLR for the Spot watches.

So is there an Intel 64bit CLR out there as well?

Is the AMD64 CLR tied to XP-64bit, or will it be optimising in a 32 bit environment?

re: The problem with being second

Grant — Tue, 07 Sep 2004 17:54:00 GMT

Yes, the AMD64 JIT will support the Intel processors that implement the x64 extensions, as well as the Itanium family. These 64-bit JITs will only work on a 64-bit CLR on a 64-bit OS (Windows Server 2003 for x64 is in beta IIRC).

Also don't get me wrong, the x86 JIT is working on a fair number of their own optimizations to speed things up.
--Grant

re: The problem with being second

anonymous — Tue, 07 Sep 2004 18:19:00 GMT

Top wish for this JIT (and the next version of the 32-bit one):
Allow inlining of functions that operate on value types. 3D vector math would be soo much faster and more convienent if you could use a vector class without worrying that every little vec3+vec3 will turn into a full function call..

re: The problem with being second

Craig Thrall — Tue, 07 Sep 2004 18:23:00 GMT

Here's a question for you. If the spec allows both behaviors, does that indicate a problem in the spec that should be revisited? Make a change to specifically say "local references will change across threads?"

re: The problem with being second

Grant — Tue, 07 Sep 2004 18:31:00 GMT

That not what's happening. Look at the spec for the C# keyword volatile or the volatile IL opcode prefix. Unless those are present the JIT/runtime is free to assume that only 1 thread is modifying the variable at a time, and therefore can perform agressive optimizations that make your app run faster (like putting things in registers). That's all in the spec. The problem is that most people don't read the spec, they just try it and see if it works. :(
--Grant

re: The problem with being second

Jeroen Frijters — Tue, 07 Sep 2004 19:16:00 GMT

I can't for the life of me figure out why you think this optimization is legal.

If I understand you correctly, you are effectively saying the contents of a local variable can be affected by another thread, right? But when Craig said this you reply that that is not the case, but your explanation of volatile is totally incorrect. Volatile loads/stores act as a memory barrier, but that's basically irrelevant here, we're looking at the behavior of a single thread and your optimization clearly violates the spec:
>>>
Conforming implementations of the CLI are free to execute programs using any technology that guarantees, within a single thread of execution, that side-effects and exceptions generated by a thread are visible in the order specified by the CIL.
<<<

re: The problem with being second

Grant — Tue, 07 Sep 2004 19:46:00 GMT

OK. Show me how replacing all occurances of the local 'lbuckets' with the member variable 'buckets' violates that statement. The replacement will not change the order of exceptions, nor any of the side-effects on a *single* thread.

On multple threads, yes the side-effects definitely change, but the spec is clear about only applying to a single thread.

You are correct about volatile acting as memory barriers. That basically means that reading and writing suddenly become side-effects. The original code has only one read of the member variable 'buckets'. If it was a volatile read, the JIT would be forced to only have one read and thus force the JIT to use that read to copy into a non-volatile local (as the user intended). If it didn't and instead tried to replace all occurances of 'lbuckets' with 'buckets' it would be violating the rule because now there are more memory barriers. Hence the need for volatile.
--Grant

re: The problem with being second

Ryan Lamansky (Kardax) — Wed, 08 Sep 2004 02:14:00 GMT

"To a amateur, if it works, it's right. To a professional, if it's right, it works".

I welcome any new optimizations, even if they happen to break someone's buggy code.

re: The problem with being second

Dmitriy Zaslavskiy — Wed, 08 Sep 2004 15:11:00 GMT

I just hope when MS guys will realize how much code is broken by those optimization they won't simply remove it, but rather make it an opt-in atrribute. Maybe add another flag to CompilationRelaxations

re: The problem with being second

Ryan Lamansky (Kardax) — Thu, 09 Sep 2004 11:59:00 GMT

I gave this some thought, and I really don't think very much code would be broken. Relatively few .NET applications use threading, and those that do invariably do it to improve the speed or responsiveness of their program... any optimizations would be good news.

Not to mention, we're talking about a Major New Release--this is 2.0 coming up, not 1.2. This is the time for riskier changes.

CompilationRelaxations is worth considering, but I don't think using it to support the small amount of flawed code affected by this issue is the right direction.

re: The problem with being second

Jeroen Frijters — Thu, 09 Sep 2004 13:49:00 GMT

I disagree with your (and apparently most of the CLR team's) reading of the spec (and even if I'd agree, I'd say the spec is broken), but let's assume for a moment that I agree with your reading, in that case the only place where things can go wrong is the "lbuckets.Length" that is passed into the InitHash method. The subsequent ones that you highlighted are not allowed to be read from the field, because InitHash contains a virtual method call to GetHash and that effectively prevents the JIT from seeing if anyone else on this thread is going to write to the buckets field.

Some Clarifications

GrantRi's WebLog [MS] — Wed, 15 Sep 2004 23:32:00 GMT

Safely firing an event, Part 3

jaybaz [MS] WebLog — Fri, 17 Sep 2004 02:52:00 GMT

re: The problem with being second

Matthew W. Jackson — Fri, 17 Sep 2004 00:54:00 GMT

Is this really an issue in this case? I thought that Hashtables weren't intended to be thread-safe, and if you're using them in two threads and are modifying the data, it's up to the caller to use monitors or other synchronization techniques. If one thread calls Add and another calls ContainsKey without locking, that's not the fault of the code or the JIT, is it?

Volatile reads and writes in VB

Panopticon Central — Thu, 30 Sep 2004 22:28:00 GMT

How to be more volatile.

re: Good post on running/writing/compiling managed binaries as 32-bit or 64-bit

GrantRi's WebLog [MS] — Mon, 18 Oct 2004 22:46:00 GMT

re: Field access versus local variable access performance

Wintellog — Mon, 22 Nov 2004 21:57:00 GMT

Volatile reads and writes in VB

Panopticon Central — Mon, 25 Jul 2005 02:17:06 GMT

How to be more volatile.

Volatile reads and writes in VB

Panopticon Central — Wed, 27 Jul 2005 09:34:48 GMT

How to be more volatile.

The CLI memory model, and specific specifications

Jon Skeet's Coding Blog — Mon, 27 Nov 2006 00:49:18 GMT

A while ago, I was directed to a disturbing (in my view) post on GrantRi's blog, to do with the .NET

Actors and Actresses » Archive du blog » GrantRi’s WebLog [MS] : The problem with being second

Sat, 05 Jan 2008 00:25:52 GMT

PingBack from http://actors.247blogging.info/?p=4352

Famous Quotes » GrantRi’s WebLog [MS] : Good post on running/writing/compiling managed …

Sat, 05 Jan 2008 13:46:57 GMT

PingBack from http://famousquotes.247blogging.info/?p=1131

Dinner and a Movie » GrantRi’s WebLog [MS] : The problem with being second

Dinner and a Movie » GrantRi’s WebLog [MS] : The problem with being second — Thu, 20 Mar 2008 23:38:22 GMT

PingBack from http://dinnermoviesblog.info/grantris-weblog-ms-the-problem-with-being-second/