This is NOT for the Bartok/Phoenix compilers but for the Visual C++ compiler !

This is NOT for an incubation project but for shipping (could be internally thought) products !

Finally some Midori ideas goes into product teams !

Hmmm....maybe .NET 5 will be the new Visual Basic 5 which compiles the P-Code to native using Visual C++ compiler.

So Going Native doesnt necessarily mean Going C++ and we can optimize for both programmer productivity and performance, how about that ?

https://careers.microsoft.com/jobdetails.aspx?jid=81769
http://www.compilerjobs.com/db/jobs_view.php?editid1=648

We are looking for a software engineer to fill a critical role in the C++ compiler team at Microsoft. The successful candidate must be able to (1) help us ship new compilers and tools (2) bang out elegant scripting code, (3) work hand-in-hand with some of the best compiler architects in the business, and (4) demonstrate a strong desire to improve all automation used to ship the tools compile all major products in Microsoft.

We offer a chance to learn compiler and system technology from the ground up while helping to shape the future of C, C++ and C#. For Windows 8, Microsoft has invested in the automatic vectorization and parallelization of unaltered C++ in an initial effort to move the entire Microsoft platform to all the new hardware from Intel, AMD and ARM. Microsoft has an ambitious agenda to take those technologies to the next level and to ship enhancements to the compiler tool chain on a quarterly cadence. We need a key engineer to help us accomplish that aggressive goal while using this as an opportunity to learn about the development of compilers and operating systems.

To accomplish this, the candidate will work on improving all the automation used to stress the compiler while building Win 8, SQL and Office. This includes development activities for an essential automation system that is used for stressing the live development compiler while helping the development team understand and resolve key failures. As Microsoft continues to advance the state of the art with automatic vectorization and automatic parallelization capabilities across dissimilar architectures the need to grow the optimizer team is a priority for the company. This compiler will be used for both C++ and C#.

Specifically this work will include:
• Creating new automation for stressing the new compiler
• Improve all the existing automation for building and stressing Windows and SQL
• Interface to the Windows, SQL, Phone and Console teams to deliver new compilers
• Work to coordinate compiler development with PM and QA teams
• Do performance analysis for code quality and throughput
• Create new harnessing and automation for a new effort to compile C# using the native C++ compiler
• Working effectively across both managed and native, compilers and runtimes.
• Learning compiler technology by working alongside senior compiler architects building new compiler technology that ships internally on a regular and short cadence
Since the compiler is used to compile all the C++ software in the company the candidate must respect mission critical correctness by helping to identify the overall quality of the compiler for throughput, correctness, performance and code size. This is a great opportunity for an engineer that would like to learn about compiler and/or system programming while making sure it ships with as little friction as possible.

https://careers.microsoft.com/jobdetails.aspx?jid=81397

We are looking for an exceptional candidate for the C++ optimizer team at Microsoft. The successful candidate must be able to (1) design new compiler innovations for both native and managed code, (2) bang out elegant code, (3) work hand-in-hand with some of the best compiler architects in the business, and (4) demonstrate a strong desire to learn. We offer a chance to help shape the future of high performance computing for many platforms by exploiting the ever wider vectors and the higher numbers of cores on each new generation of microprocessor that Microsoft will have to respond to in the next 12 to 18 months. For Windows 8, Microsoft has invested in the automatic vectorization and parallelization of unaltered C++ in an initial effort to move the entire Microsoft software platform to all the new hardware from Intel, AMD and ARM. Microsoft has an ambitious agenda to take those technologies to the next level. We want to expand that technology for both C++ and now C#.

To accomplish this, the candidate will work on improving the optimization, vectorization and parallelization phases of the Microsoft C++ compiler both for C++ and C#. This includes both significant research and/or simultaneous product development activities. As Microsoft continues to advance the state of the art with automatic vectorization and automatic parallelization capabilities across dissimilar architectures the need to grow the optimizer team is a priority for the company. Since we are taking on a managed language like C# the candidate will assist in compiling MSIL byte codes using the native C++ compiler.

Specifically this work will include:
• engineering parts of the reader for MSIL and type loader
• providing technical leadership across all the components in the new compile paths
• coordination with both the PM and QA teams
• performance analyis
• creating a native compiler internal representation the existing compiler can optimize
• the design and implementation of new managed optimizations to augment the existing optimizer like range check elimination or speeding up C# constructs on vector machines
• engineering and co-designing the ability to emit a new object file format that will support rapid linking and
• fixing all existing phases of the compiler so that managed code can be correctly and efficiently compiled with the new auot-vectorizing/auto-parallelizing Win 8 compiler
• working effectively across both domains – managed and native, compiler and runtime.
Since the compiler is used to compile all the C++ software in the company the candidate must respect mission critical correctness by helping to improve the overall quality of the compiler for throughput, correctness, performance and code size as all members of the team currently do.

Someone correct me if I'm wrong here, but if you have deterministic finalization that works with move semantics as you have with C++ 11, which allows you to avoid falling back to raw pointers and having to manage memory outside of destructors etc..., then performant C++ and C# become quite similar.  The compiler can make the C# behave as it would if it were managed code (GC wise ... ignoring CAS or other CLR services), but better since there's true deterministic finalization.  Since older C++ compilers didn't have move semantics for reference types, then trying to get C# code to compile down to native would result in copy semantics and horrible performance. 

Case studies tend to show that C# produces better performance than C++.  I've seen where people have set out to show how bad C# performs compared to native code, and change their minds once they see the results.

This isn't meant to troll, but I'm genuinely curious since this is not the typical path taken.

20 hours ago, Richard.Hein wrote

Awesome.  There's less and less reason to have a CLR or VM if you have a compiler that can take in various languages and target various architectures just as well - and better.  There's a session on auto vectorization that was just live today ... I only caught a part of it and plan to check it out this weekend.

Someone correct me if I'm wrong here, but if you have deterministic finalization that works with move semantics as you have with C++ 11, which allows you to avoid falling back to raw pointers and having to manage memory outside of destructors etc..., then performant C++ and C# become quite similar.  The compiler can make the C# behave as it would if it were managed code (GC wise ... ignoring CAS or other CLR services), but better since there's true deterministic finalization.  Since older C++ compilers didn't have move semantics for reference types, then trying to get C# code to compile down to native would result in copy semantics and horrible performance. 

As I see it, the challenge to get C# get deterministic finalization is to make it able to break out of its dependence on the GC. Extending the language would just beef up the unsafe part of the language; what would be really cool would be to get the compiler spot by usage when a reference can be (safely and verifably) converted into an unique_ptr, a shared_ptr, or even just allocate it on the stack.

23 hours ago, Bass wrote

It's hilarious how much detail you can get about a company's strategy just by reading their job openings.

Oh its not about 'company strategy' but just some geeky technology tibits, of course its just speculating but speculating is always fun ! Especially when MS is not as open as before.

14 hours ago, SteveRichter wrote

What does this mean for Anders? Will he have to answer to the native language team before any additions to C#?

Well, I read it carefully and sometimes it actually says the compiler is compiling MSIL, so it could work like NGEN/JIT or a post-compiling phase. of course the C# frontend (Roslyn?) could be integrated too, to provide more analysis and optimizing possiblities. So basically Anders owns the frontend and VC team has the backend (or one of the backends) I guess.

9 hours ago, bondsbw wrote

@magicalclick: Assuming you were not attempting to write drivers in C#, what about it is slower or supports less hardware than C++?  (Of course, I'm assuming you are still targeting Windows...)

Case studies tend to show that C# produces better performance than C++.  I've seen where people have set out to show how bad C# performs compared to native code, and change their minds once they see the results.

This isn't meant to troll, but I'm genuinely curious since this is not the typical path taken.

Tell the news to Herb Sutter ! or read this :

https://careers.microsoft.com/jobdetails.aspx?jid=76831

Managed code can be much higher performing when it is compiled by an ahead-of-time advanced optimizing compiler to native code.

To my understanding, it is embeded system. So, I guess they don't have .Net for it. Personally I don't know the whole story behind it.

I agree with the performance statement. Although if you really start to crunch the performance, C++ is definitly faster. The caveat is, crunching that performance is very challenging and often makes more mistakes on the way. But, some companies do have the resources for that.

C

That will solve all of Bill Gates's pesky problems with humanity and speculation once and for all.

3 hours ago, Sven Groot wrote

@Charles: But speculation is fun...

Indeed it is. Just don't take it too seriously (it's fun...)
C

As Linus Torvalds said : Just For Jun.

C

That was fun.

19 hours ago, DeathByVisualStudio wrote

OMG! Is this the end of .NET?

That was fun.

Of course not, its a Nirvana ! of the Phoenix ! (Nirvana could be a perfect codename btw)

VB5 is not the end of VB right ? that was VB6 ...... oh wait.

No, this is just a logical thing when the CLR want to reach resource-constrained devices,
do you think the managed language teams will sit there listening Herb Sutter bragging about
the performance advantages of C++/native code and then give up and do nothing ? huh.

At least, a much-better optimized NGEN wont kill the platform right ?

20 hours ago, Charles wrote

@felix9: Good boy.

C

So, may I go on ? talking about 'incomplete technical information' or 'partial data', there are indeed so many questions and mysteries about this thing.

What about the CLR ? will it be exactly the same CLR too ? or something like SLR ? I guess the Redhawk itself is somehow dead, because a seperate and different runtime is not practical, if you can't port existing .NET code directly, then its not that useful.

Then how compatible will the language be ? IIRC Bartok has some limitations on language features right ? (could be wrong though) Can I set 'Compile to native' as a checkbox, like in VB5 ? or could it be a seperate kind of project type with some rules ?

IIRC the benefits of VB5 native compiling were limited because most of the code calls into the runtime library / COM anyway and wont gain much from native code in itself, except heavy math routines. And in the WinRT world you can always write those code in native languages. so ... I guess Herb Sutter was right about the inlining of templates, without virtual calls, C++ is still better.

What about P/Invoke and reversed P/Invoke ? IIRC one good thing about Redhawk is low cost and seamless calls between C and C# code, right ? is this why we wont need XNA anymore ?

What about the Metadata ? Reflections ? Emit ?

Hmmmm..... really want to hear someone really knows what they are talking about to talk !

[/quote]

yeah, I do not follow at all how a C++ WinRT app is more efficient and less power using than C# when the majority of the time the app is in the WinRT.  And if a modern C++ app is supposed to use smart pointers, how is that more efficient that C# references?  I thought the lesson learned by the designers of the GC was that reference counting was slower than garbage collecting.

1 day ago, felix9 wrote

As Linus Torvalds said : Just For Jun.

No no it's Just For Jon. You see the CLR team is amazed at the Skeet's stack overflow rep. Maybe if they change the compiler he'll be stumped for a while and everyone else can get a chance to ask questions.

Note: This is a lie.

13 minutes ago, felix9 wrote

*snip*

Of course not, its a Nirvana ! of the Phoenix ! (Nirvana could be a perfect codename btw)

VB5 is not the end of VB right ? that was VB6 ...... oh wait.

No, this is just a logical thing when the CLR want to reach resource-constrained devices,
do you think the managed language teams will sit there listening Herb Sutter bragging about
the performance advantages of C++/native code and then give up and do nothing ? huh.

At least, a much-better optimized NGEN wont kill the platform right ?

Thanks for humoring my sarcasm. Though VB5 => VB6 is not a fair comparison. VB6 => .NET I think is more along those lines especially if some incarnation of the CLR isn't part of the Nirvana's picture.

True about NGEN.

3 hours ago, SteveRichter wrote

... And if a modern C++ app is supposed to use smart pointers, how is that more efficient that C# references?  I thought the lesson learned by the designers of the GC was that reference counting was slower than garbage collecting.

I believe that needs to be put in the right context. Garbage collection can be more performant than reference counting, so if you are designing a language that relies heavily on managed memory, a GC is the way to go. But there's the rub... C++ offers you options that allow you to express your code without using reference counting at all, possibly at the expense of memory safety.

Take for instance an object that is not meant to survive the scope it's allocated in. Assuming it's a reference type, in C# it gets invariably allocated on the managed heap and you incur collection costs. In C++, you could use a unique_ptr, or even just allocate it on the stack. Sure, that's not foolproof, but the gains in performance and memory pressure are significant.

That's where a smarter compiler could really help: in C++ it could be more aggressive in detecting dangerous situations; in C#, it could detect cases in which the lifetime of an object can be safely determined at compile time and get them out of the hair of the GC (and possibly onto the stack).

This is just the tip of the iceberg, but I already rambled enough.

5 days ago, blowdart wrote

*snip*

No no it's Just For Jon. You see the CLR team is amazed at the Skeet's stack overflow rep. Maybe if they change the compiler he'll be stumped for a while and everyone else can get a chance to ask questions.

Note: This is a lie.

LMAO! OK.

sorry for the typo.

I'm no expert in this, but I think reference counting is also more predictable (latency wise) making it superior memory management method for real time applications. GC performance depends on the GC algorithm, but I never recall seeing a GC that was conclusively proven to be faster than reference counting. One thing GC does have that reference counting does not is the ability to handle circular references though.

10 minutes ago, Bass wrote

@Blue Ink:

One thing GC does have that reference counting does not is the ability to handle circular references though.

Isn't that why people use weak references?

13 hours ago, Bass wrote

I'm no expert in this, but I think reference counting is also more predictable (latency wise) making it superior memory management method for real time applications. GC performance depends on the GC algorithm, but I never recall seeing a GC that was conclusively proven to be faster than reference counting. One thing GC does have that reference counting does not is the ability to handle circular references though. 

The performance of reference counting is pretty much constant with respect to the amount of available memory. Conversely, garbage collectors will improve steadily as you add more memory (interesting special case when the amount of memory is infinite). So, if GC's aren't ahead right now, they will eventually be.

yeah, I do not follow at all how a C++ WinRT app is more efficient and less power using than C# when the majority of the time the app is in the WinRT.  And if a modern C++ app is supposed to use smart pointers, how is that more efficient that C# references?  I thought the lesson learned by the designers of the GC was that reference counting was slower than garbage collecting.

But for an application where it makes sense to talk about performance *at all*, the majority of the time will *not* be spent in WinRT.

But, and this is the important point, no one said anything about reference counting.

Smart pointers != shared pointers.

Shared pointers use reference counting, and they are *a* form of smart pointer. They are, by far, the slowest kind of smart pointer, and certainly not the first one you should look to.

Most of the time, you can/should use something like unique_ptr, which is, well, optimal. There is literally no overhead to using it.

And even smart pointers aren't the final word. They are just a single example of RAII. RAII is how *all* resources in C++ are managed. Not just memory, but sockets, files, locks and anything else.

And resource management is not the reason why C++ can be faster than C#. The reason for *that* is that C++ supports a number of way to produce zero-overhead abstractions.

So really, you're barking up the wrong tree. Overuse of shared pointers is one way in which (bad) C++ code can be made incredibly slow. But no one said to use shared pointers everywhere in modern C++ code. They said to use *smart pointers*.

If you just tag a reference count onto every object in C++, then it's going to be slow. But in C++, you don't *need* to reference count the vast majority of objects, because you (and the compiler) *know* when they should be destroyed (hint: when they go out of scope)

47 minutes ago, jalfd wrote

Most of the time, you can/should use something like unique_ptr, which is, well, optimal. There is literally no overhead to using it.

How does unique_ptr work?   Why do you have to use the move function when assigning 1 unique_ptr to another?

  unique_ptr<wstring> pMsg(new wstring) ;  *pMsg = L"The unique_ptr class supersedes auto_ptr" ;  ::OutputDebugString(pMsg->c_str( )) ;//  auto pMsg3 = pMsg ;  // compile error.  auto pMsg3 = move(pMsg) ;  ::OutputDebugString(pMsg3->c_str( )) ;

and how to build a collection of unique_ptr?

  vector<unique_ptr<wstring>> msgList;  msgList.push_back(pMsg3) ;  // compile error.

http://msdn.microsoft.com/en-us/library/dd293668.aspx
http://msdn.microsoft.com/en-us/library/ee410601.aspx#2

If you want to share ownership of memory between multiple smart pointers, you would use shared_ptr instead as its reference count is adjusted on copy/assignment, etc.

As for the std::vector of std::unique_ptr, this can be done with emplacement, this will construct the unique_ptr inside the vector itself with the raw pointer passed in. But i think with move semantics, std::vector<std::wstring> might be more appropriate.

I'm still figuring out all of the c++11 guidance myself, but maybe something like this:

std::wstring msg(L"The unique_ptr class supersedes auto_ptr");
::OutputDebugString(msg.c_str( ));
msgList.push_back(std::move(msg));

3 minutes ago, banjomatic wrote

 

I'm still figuring out all of the c++11 guidance myself, but maybe something like this:

1 2 3

std::wstring msg(L"The unique_ptr class supersedes auto_ptr"); ::OutputDebugString(msg.c_str( )); msgList.push_back(std::move(msg));

got it. thank you. I ask about collections because they are a basis of XAML programming, I am kind of sceptical of C++ collections performing well and being easy to use.

May 22, 2012 at 7:35 PM, SteveRichter wrote

I thought the lesson learned by the designers of the GC was that reference counting was slower than garbage collecting. 

Reference counting is orders of magnitude faster than performing a GC.

The reason .NET and other managed languages choose a GC is it detects circular references.

Consider a linkedlist with reference counting:

func main()
{

LinkedListNode i = new LLNode();
// ref count of i = 1
LinkedListNode j = new LLNode();
// ref count of j = 1
i->Flink = j;
// ref count of i = 2
j->Blink = i;
// ref count of j = 2

i = nullptr;
// ref count of i = 1
j = nullptr
// ref count of j = 1

}

So now we've leaked i and j. Nobody points to them, but their ref-count is 1 (and hence won't be deleted) since i points to j and j points to i.

GC solves this problem by saying that both i and j are not reachable at the end of main, and hence are eligible for collection.

any news on this project ?

But, in the WP8 Cloud JIT story something called MDIL was revealed, dont know if its related but quite possible, because MDIL seems to be at the right level a native optimizer could be working on.

Wondering if we will see this on the Desktop too...