Archived

This topic is now archived and is closed to further replies.

CProgrammer

Longhorn and ASM

Recommended Posts

When longhorn coms out, will Assembler still be good for optimizing. As I''ve heard that longhorn will be based on the .NET frameowrk meaning c# will be native, that leaves me to wonder wether C# code will be faster than assembler code, assuming both versions are perfectly programmed. Any thoughts? -CProgrammer

Share this post


Link to post
Share on other sites
quote:
Original post by CProgrammer
When longhorn coms out, will Assembler still be good for optimizing. As I''ve heard that longhorn will be based on the .NET frameowrk meaning c# will be native, that leaves me to wonder wether C# code will be faster than assembler code, assuming both versions are perfectly programmed.



C# will be native to the OS, whereas ASM is native to a particular processor or family of processors. There still needs to be translation between the higher level language and machine code, so ASM will still be the faster option(Assuming you can write perfectly optimised code that is better than the C# compiler!)

James

Share this post


Link to post
Share on other sites
quote:
Original post by Valderman
There will most likely be some MSIL ASM you can use.

Or you could always screw Longhorn and hope everyone else does too.


[My Image Gallery (WIP)][Greatest Tetris clone evar!][Return your stolen MP3s]

[edited by - Valderman on January 15, 2004 9:45:11 AM]


There is MSIL ASM and you are able to use it. I have one book on the subject as I plan to learn and use it for optomizing some parts of my C# applications.

Share this post


Link to post
Share on other sites
quote:
Original post by jamessharpe
quote:
Original post by CProgrammer
When longhorn coms out, will Assembler still be good for optimizing. As I''ve heard that longhorn will be based on the .NET frameowrk meaning c# will be native, that leaves me to wonder wether C# code will be faster than assembler code, assuming both versions are perfectly programmed.



C# will be native to the OS, whereas ASM is native to a particular processor or family of processors. There still needs to be translation between the higher level language and machine code, so ASM will still be the faster option(Assuming you can write perfectly optimised code that is better than the C# compiler!)

James





Actually unsafe ASM takes a large speed hit if you are talking applications for Windows Longhorn onwards. Also note that for 80-90% of users.. unmanaged code will simply NOT run anymore. The security options are defaulted not to let "unsafe" applications run. So if a user tries to it will pop up a box warning them of the potential security and stability problems from running an unmanaged application. That alone puts managed code on the forefront because 80-90% of those users are NOT going to let something "UNSAFE WITH POTENTIAL SECURITY AND STABILITY RISKS" run on their system. =]

Share this post


Link to post
Share on other sites
quote:
Original post by DrPizza
What the fuck does that mean?

It''s not like Longhorn is going to disallow native code.




Correct.

You are able to use native code.. but there is a performance hit (currently benchmarks are showing C# running faster than unmanaged C++ with ease. We are talking a good 10-40% faster depending on the application. BUT this may change by release so who knows).

Also there are the security issues and the fact that most users won''t run "unsafe" applications.

Please note WinXP -> Win Longhorn is a paradigm shift in Microsoft operating systems. It is just like the DOS->win95 shift. How many DOS programs do you use today? I saw them all die out about a year or two after people claimed the change would never happen =]

Share this post


Link to post
Share on other sites
quote:
You are able to use native code.. but there is a performance hit (currently benchmarks are showing C# running faster than unmanaged C++ with ease. We are talking a good 10-40% faster depending on the application. BUT this may change by release so who knows).

What the hell are you talking about? Certainly my copy of Longhorn shows no such thing. How on earth are they going to make native code slow down?

quote:
Also there are the security issues and the fact that most users won''t run "unsafe" applications.

Most users will have no choice but to run unsafe applications, so again one wonders what you''re talking about.

Share this post


Link to post
Share on other sites
quote:
Actually unsafe ASM takes a large speed hit if you are talking applications for Windows Longhorn onwards.

No it doesn''t.

quote:
Also note that for 80-90% of users.. unmanaged code will simply NOT run anymore.

Yes it will.

quote:
The security options are defaulted not to let "unsafe" applications run.

No they aren''t.

quote:
So if a user tries to it will pop up a box warning them of the potential security and stability problems from running an unmanaged application.

Screenshots, please.

quote:
That alone puts managed code on the forefront because 80-90% of those users are NOT going to let something "UNSAFE WITH POTENTIAL SECURITY AND STABILITY RISKS" run on their system. =]

That they install ActiveX controls with that same warning without the slightest thought suggests otherwise.

Share this post


Link to post
Share on other sites
Its when the unmanaged code interacts with the OS that the spped hit will occur. This is because that the API calls that unmanaged code uses will no longer be native to the OS: they will be wrapper functions for the managed API(at least this is how I perceive it being done). This means that GUI apps are the ones that are most likely to be taking a speed hit. Apps that do pure number crunching are not(or at least shouldn''t) see any speed hit.

Share this post


Link to post
Share on other sites
quote:
Original post by jamessharpe
Its when the unmanaged code interacts with the OS that the spped hit will occur. This is because that the API calls that unmanaged code uses will no longer be native to the OS: they will be wrapper functions for the managed API(at least this is how I perceive it being done). This means that GUI apps are the ones that are most likely to be taking a speed hit. Apps that do pure number crunching are not(or at least shouldn''t) see any speed hit.




100% correct with this statement.

Share this post


Link to post
Share on other sites
quote:
Original post by _the_phantom_
and lets be honest here, how many ppl MMX/SSE(2) optermise their interaction with the win32 api now.... I thought so


I think the reason for this lack of optimisation is that projects that actually require this kind of optimisation(games!!) rarely get finished by ''hobby'' programmers and the place to be optimising with MMX/SSE(2) is at the end of the project or when you know that the code speed is a bottleneck - which is something that not many people are good at spotting. It''s usually a case with most beginner(and intermediate) level programmers of lets make this code run as fast as I can!

James

Share this post


Link to post
Share on other sites
quote:
Actually unsafe ASM takes a large speed hit if you are talking applications for Windows Longhorn onwards. Also note that for 80-90% of users.. unmanaged code will simply NOT run anymore. The security options are defaulted not to let "unsafe" applications run. So if a user tries to it will pop up a box warning them of the potential security and stability problems from running an unmanaged application. That alone puts managed code on the forefront because 80-90% of those users are NOT going to let something "UNSAFE WITH POTENTIAL SECURITY AND STABILITY RISKS" run on their system. =]


please tell me applications and engines developed under unmanaged C++ won''t get that "box from managed hell"...!!

And if they do, how will one "convert" our C++ code to "safety"? Without having to rewrite it completely to be managed? Does it have to pass some tests, like memory leaking or something?


[Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD][Yann L.][Enginuity]
The most irrefutable evidence that there is intelligent life in the Universe is that they haven''t contacted us!

Share this post


Link to post
Share on other sites
quote:
Original post by DrPizza
What the hell are you talking about? Certainly my copy of Longhorn shows no such thing. How on earth are they going to make native code slow down?



So because some kid that warezd a copy of Longhorn says so than it does not show such thing?

Sorry but when using Whidbey and Longhorn, yes it does show that. Both are PDC copies.

And you really think they WANT to slow down native code? Hell no! But due to the design of a managed system, it is well worth the trade-off for security and stability.. which is what the end-users want the most.


quote:

Most users will have no choice but to run unsafe applications, so again one wonders what you''re talking about.



haha this quote reminds me of back in 93-95 when I heard this EXACT quote of how DOS applications will not go away and that users will continue to use them.

All major software packages will be managed .NET ready by the time Longhorn is released (why do you think the framework was released years prior? .. to have the software ready). Also as we noticed.. DOS applications disappeared shortly after Windows release.. because end-users requested Windows versions.

Share this post


Link to post
Share on other sites
quote:
Original post by pentium3id
quote:
Actually unsafe ASM takes a large speed hit if you are talking applications for Windows Longhorn onwards. Also note that for 80-90% of users.. unmanaged code will simply NOT run anymore. The security options are defaulted not to let "unsafe" applications run. So if a user tries to it will pop up a box warning them of the potential security and stability problems from running an unmanaged application. That alone puts managed code on the forefront because 80-90% of those users are NOT going to let something "UNSAFE WITH POTENTIAL SECURITY AND STABILITY RISKS" run on their system. =]


please tell me applications and engines developed under unmanaged C++ won't get that "box from managed hell"...!!

And if they do, how will one "convert" our C++ code to "safety"? Without having to rewrite it completely to be managed? Does it have to pass some tests, like memory leaking or something?


[Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD][Yann L.][Enginuity]
The most irrefutable evidence that there is intelligent life in the Universe is that they haven't contacted us!




With Visual Studio.NET you can use the /CLR switch which compiles it managed and you are able to run perfectly fine.. you just notice a performance hit. You don't get the benefits you would see from re-writing your code purely managed.. but you will be able to run on Longhorn perfectly fine without warnings, etc.

This was done to make it easy for legacy applications (such as unmanaged C++) easy to convert in the short-term and run on the new Windows platform.

Even Microsoft states that re-writing your whole codebase managed is seen as too large of a job for an existing software package.. which is why they added the /CLR switch. Basically they only expect developers to write new appications managed.. or rewrite in managed to see performance increases compared to unmanaged /CLR switched code.

[edited by - Imperil on January 15, 2004 11:43:43 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by DrPizza
That they install ActiveX controls with that same warning without the slightest thought suggests otherwise.



lol you killed yourself with that quote. It is shown with statistics across the web that ActiveX controls are refused over 75% of the time.

I know for a fact myself working as a developer that this is the case and we try to stick with standard libraries, etc.

Especially after all of the latest virii, worms, spyware, etc.. end-users are starting to become really cautious about what is installed.

The reason for moving to a managed system is because the end-users requested security and stability over performance.. please note that it wasn't a developer decision.. but looking statistically at what the end-users want.

[edited by - Imperil on January 15, 2004 11:39:49 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by Imperil

quote:

Most users will have no choice but to run unsafe applications, so again one wonders what you''re talking about.



haha this quote reminds me of back in 93-95 when I heard this EXACT quote of how DOS applications will not go away and that users will continue to use them.

All major software packages will be managed .NET ready by the time Longhorn is released (why do you think the framework was released years prior? .. to have the software ready). Also as we noticed.. DOS applications disappeared shortly after Windows release.. because end-users requested Windows versions.



Yes, but it''s not quite the same now is it? The users view of the application will be the same, its the underlying structure that is different - this wasn''t the case with dos. Also managed c++ is OS specific - code for portable applications will still be written in unmanaged c++, why code a different version for windows only? Of course if other platforms start to implement managed systems then perhaps we will see a shift, but even then it is dependant upon the programming community - it''s taken some programmers a very long time to move from C to C++, even in cases where the benefits of C++ are quite clear-cut.

James

Share this post


Link to post
Share on other sites
quote:
Original post by jamessharpe
Yes, but it''s not quite the same now is it? The users view of the application will be the same, its the underlying structure that is different - this wasn''t the case with dos.



Please note that is what the end-users wanted the MOST. A complete GUI system with ease of use. Now that is common and the least of concerns, the end-users want security and stability in the end.. which they WILL see in the form of running unsafe code, etc.


quote:

Also managed c++ is OS specific - code for portable applications will still be written in unmanaged c++, why code a different version for windows only?



Correct in many cases. Although the .NET compact framework will be running on portable deviecs, and the Windows desktop market is still pegged at 95%+ and doesn''t seem to be changing anytime soon.

If you are coding PS2, GameCube, Linux, UNIX, etc and want to port to windows.. you would write it in unmanaged C++ and then use the /CLR switch to compile for Longhorn. Or you can go in and make the changes to have it managed.

Share this post


Link to post
Share on other sites
My curent engine was designed bottom-up to be fully polymorphic, although it is target at Win32 only.

Will there be a way for me, under the same exe, to detect the OS version, and if its LongHorn, run in managed code, and if its not, then run another code path?

Thanx, this thread is really clearing up some doubts for me.


[Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD][Yann L.][Enginuity]
The most irrefutable evidence that there is intelligent life in the Universe is that they haven''t contacted us!

Share this post


Link to post
Share on other sites
quote:
Original post by pentium3id
My curent engine was designed bottom-up to be fully polymorphic, although it is target at Win32 only.

Will there be a way for me, under the same exe, to detect the OS version, and if its LongHorn, run in managed code, and if its not, then run another code path?

Thanx, this thread is really clearing up some doubts for me.


[Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD][Yann L.][Enginuity]
The most irrefutable evidence that there is intelligent life in the Universe is that they haven't contacted us!





Well you don't really have the option of not having it as a managed package.

Before people freak out just hear me out:

Basically Microsoft has allowed for the old applications to be able to run on the new OS (TECHNICALLY you can run all of your unmanaged applications on Longhorn, and you only incur a performance hit).. EXCEPT that on the majority of users systems it will complain about being "unsafe" and that it should "shut down" the application. It has been proven over the years that when the words unsafe, insecure, etc pop up.. end-users will NOT use or install it.

BUT

That being said, you could compile your old unmanaged code using the /CLR switch and that gets rid of that problem on Longhorn, you just see a performance hit.

OR

You could write some type of launcher (in managed code) that checks OS version, and if it is pre-Longhorn than use the unmanaged engine, or if it is Longhorn+ use a managed engine.

[edited by - Imperil on January 15, 2004 2:40:52 PM]

Share this post


Link to post
Share on other sites
Thanks for the replies Imperil. What exactly does the /CLR flag do?

Does it 1)tell LongHorn to ignore that the code is unmanaged, and show no warning box or 2)Compiles certain API calls and memory managment code (new & delete) in a diferent way?

Once again, thanks for the replies


[Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD][Yann L.][Enginuity]
The most irrefutable evidence that there is intelligent life in the Universe is that they haven''t contacted us!

Share this post


Link to post
Share on other sites
quote:
Original post by pentium3id
Thanks for the replies Imperil. What exactly does the /CLR flag do?

Does it 1)tell LongHorn to ignore that the code is unmanaged, and show no warning box or 2)Compiles certain API calls and memory managment code (new & delete) in a diferent way?

Once again, thanks for the replies


[Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD][Yann L.][Enginuity]
The most irrefutable evidence that there is intelligent life in the Universe is that they haven't contacted us!





When you use the /CLR switch what happens is that your code is compiled as MSIL. When it is run for the first time on a system, it is run through the JIT and compiled to run.

Basically it's a quick and dirty way of switching unmanaged C++ applications to managed C++ applications.

This way your application is completely managed and you don't get security warnings, etc.. although you do incur a performance hit.

Now this is the part that you really have to decide on how you want to work things. Once you compile with /CLR it will run perfectly on Longhorn, just like a managed C++ or C# application, ALTHOUGH it will take a performance hit and be slower than a true managed C++ application.

So to regain performance you would probably want to either re-write in managed C++ or C#, or leave as-is and wait for the next product/version.

As of right now C# performance obliterates managed C++ performance (due to the fact C# was built solely for a managed system), but that is being worked on at this time and the performance of managed C++ is expected to get better.

[edited by - Imperil on January 15, 2004 3:05:44 PM]

Share this post


Link to post
Share on other sites