C# Programming Language

[agentgonzo]

As for the performance... I can't really tell a difference between the ShuttlePB and the ShuttlePBdotNET in Orbiter, at least not in speed terms.

The performance problems with managed systems are more of the psychological kind, I think.

Performance has always been one of the main criticisms of languages that use a virtual machine (firstly java and then C#), early java was apparently very slow compared with C/C++. However (again, from what I have read) this is now not true in general anymore and whilst the majority of java applications run slower than equivalent native code applications, the difference is negligible (I've heard 2-10% quoted as the norm) and in a lot of cases, this doesn't matter. In some cases, the optimisation in java/C# and the libraries themselves mean that the native code applications have been clocked to run slower than the bytecode. Memory footprint will always be larger in bytecode applcations though due to the VM, but when projects get large, the ~30MB overhead on a 1.5GB footprint again becomes negligible.


-----Post Added-----

Something I wasn't aware of before I tried out .NET development for Orbiter - especially OMP - was the capability of .NET being truly platform-independent....but the application itself stays the same. Not only the source-code but the binary.

The joy of languages that compile to run in a virtual machine. As long as your platform has a virtual machine to run it, it can be run on any platform.

The thing that's always made me wonder is why java as a language was always hailed as great because it's platform independent. As far as I can tell, this is just the way that it is compiled and thus a feature of the compiler rather than the language*. As far as I know, you could write a compiler for C++ (ignoring all the system-dependent libraries) that would compile the code to bytecode which would then be run on a virtual machine on any platform in exactly the same way.



*I know that java was designed with this in mind and that it's hard to differentiate between the language definition itself and the compilers, but I would see the cross-platform nature of java as a feature of the compiler and implementation rather than the language.

 

[Face]

Performance has always been one of the main criticisms of languages that use a virtual machine (firstly java and then C#), early java was apparently very slow compared with C/C++. However (again, from what I have read) this is now not true in general anymore and whilst the majority of java applications run slower than equivalent native code applications, the difference is negligible (I've heard 2-10% quoted as the norm) and in a lot of cases, this doesn't matter. In some cases, the optimisation in java/C# and the libraries themselves mean that the native code applications have been clocked to run slower than the bytecode. Memory footprint will always be larger in bytecode applcations though due to the VM, but when projects get large, the ~30MB overhead on a 1.5GB footprint again becomes negligible.

Indeed. I'd like to add, that one technology coming along with managed languages made the later look like memory hogs: XML. .NET made XML so easy that almost every .NET application made literally everything with XML (even communication channels). This is a mistake IMHO, because XML is not a very efficient data format. It never tried to be...
Thinking about it, XML became a kind of UMMU for .NET applications. As soon as there is some app out, calls are like "Can it do XML (export)?"...

If you use .NET-language, you still have to design your data structures well to ensure memory efficiency. This fundamental concept tends to be ignore by .NET-developers.

regards,
Face

 

[Urwumpe]

Depends on how you develop them - I know from Java development, that many large small objects (for example: Hex tiles in a board game) can easily blow the memory demands ad absurdium. C++ has a better handling of flyweight objects - as you can write it yourself.

C# and Javas garbage collection are also an advantage IMHO for beginners and rapid prototyping, but hardly for more advanced projects. It is a "one size fits all" solution, made to support a large range of applications. The pitfalls of C++ are an advantage at the point, you need control over your memory allocations (Yes, you can have flyweight objects in Java and C#, but don't get me started on the pitfalls required to have them work fast).

Every language has it's place... and I think C++ has it's place when you want speed and low memory consumption, and think that life is too short to learn assembler.

You can't put Turrican 2 into a 64 KB executable with C#.


And XML is not made for being small or time efficient. It was made for being machine-readable even when your tapes had been partially eaten by rats.

 

[Face]

The joy of languages that compile to run in a virtual machine. As long as your platform has a virtual machine to run it, it can be run on any platform.

The thing that's always made me wonder is why java as a language was always hailed as great because it's platform independent. As far as I can tell, this is just the way that it is compiled and thus a feature of the compiler rather than the language*.

Absolutely. Java was simply the first system to make the concept of interpreted byte code popular. If we like to go to academic levels, you can say that every computer language is similar to Java, because the compiler creates byte code interpreted by the CPU. IIRC, there was even someone trying to build a Java CPU - capable of accepting Java byte code natively - a while ago.

As far as I know, you could write a compiler for C++ (ignoring all the system-dependent libraries) that would compile the code to bytecode which would then be run on a virtual machine on any platform in exactly the same way.

In fact, C++/CLR is such a compiler. You can create .NET assemblies using the C++ syntax. M$ people obviously wanted to make the transition from unmanaged to managed as smooth as possible by the term IJW (it just works). The idea was to take a C++ VS project, set a compiler option to /clr, compile and presto... .NET assembly doing the same as native DLL.
Of course, to fully use .NET capabilities they introduced new keywords like "ref" for defining .NET classes instead of C++-classes (being nothing else than structs) or "nullptr" for null references. So the IJW became more like a joke to me... :lol:

regards,
Face

 

[agentgonzo]

XML. .NET made XML so easy that almost every .NET application made literally everything with XML (even communication channels). This is a mistake IMHO, because XML is not a very efficient data format.

This is something that's really bugged me with .NET too. For a lot of catch-all applications (as Urwumpe said), it's fine, but in the systems we make, I'd much rather send the data across as a memcpy from a struct than serialised XML. It's so easy (in C/C++ at least) to then just do a memcpy at the sending and receiving end to get the network packet back into your structure and doesn't bloat the network with a lot of unneccesary human-readable bloat that will never get read by a human.


-----Post Added-----

In fact, C++/CLR is such a compiler. You can create .NET assemblies using the C++ syntax. M$ people obviously wanted to make the transition from unmanaged to managed as smooth as possible by the term IJW (it just works). The idea was to take a C++ VS project, set a compiler option to /clr, compile and presto... .NET assembly doing the same as native DLL.
Of course, to fully use .NET capabilities they introduced new keywords like "ref" for defining .NET classes instead of C++-classes (being nothing else than structs) or "nullptr" for null references. So the IJW became more like a joke to me...

I'd forgotten about C++/CLR. I remember looking at it a while ago and being absolutely horrified by it. They have tried to keep it as close to C++ as possible, whilst still throwing in .NET gooeyness. This means that you get two different pointers (namely * and ^), two 'new' operators and two 'delete' operators. One for managed code and one for unmanaged code. To me that was just ghastly and I ran away screaming. Now, if I use C++, it's native and if I want to use .NET it's all in C#.

 

[Face]

Depends on how you develop them - I know from Java development, that many large small objects (for example: Hex tiles in a board game) can easily blow the memory demands ad absurdium. C++ has a better handling of flyweight objects - as you can write it yourself.

C# and Javas garbage collection are also an advantage IMHO for beginners and rapid prototyping, but hardly for more advanced projects. It is a "one size fits all" solution, made to support a large range of applications. The pitfalls of C++ are an advantage at the point, you need control over your memory allocations (Yes, you can have flyweight objects in Java and C#, but don't get me started on the pitfalls required to have them work fast).

Hm. I always use flyweight objects without such problems. Can you give a more detailed example, please, or better yet, your definition of flyweight object?

Also, I think especially for more advanced projects garbage collection is an advantage. You can of course control garbage collection as it suits you, at least in .NET (don't know details about Java in this regards).

Every language has it's place... and I think C++ has it's place when you want speed and low memory consumption, and think that life is too short to learn assembler.

You can't put Turrican 2 into a 64 KB executable with C#.

Agreed. But I'd like to see Turrican 2 written in BrainF#ck .

And XML is not made for being small or time efficient. It was made for being machine-readable even when your tapes had been partially eaten by rats.

Damn rats...

regards,
Face


-----Post Added-----

I'd forgotten about C++/CLR. I remember looking at it a while ago and being absolutely horrified by it. They have tried to keep it as close to C++ as possible, whilst still throwing in .NET gooeyness. This means that you get two different pointers (namely * and ^), two 'new' operators and two 'delete' operators. One for managed code and one for unmanaged code. To me that was just ghastly and I ran away screaming. Now, if I use C++, it's native and if I want to use .NET it's all in C#.

Well, what should I say... you're right. It's just so that you need it, if you do wrappers like Orbiter.NET, so I'm glad to have the possibility to use .NET objects in C++ code at all. Have you seen the first version of C++/CLR (.NET 1.1)? Now THAT was ugly.. squared...

regards,
Face

 

[yagni01]

Also, I think especially for more advanced projects garbage collection is an advantage. You can of course control garbage collection as it suits you, at least in .NET (don't know details about Java in this regards).

Sort of. You can tell the JVM which (of a handful) GC strategy to use.


-----Post Added-----

Actually, it is made for running on IBM System/4Pi machines - which are compatible to IBM System/360.

Actually, the language structure is more like Pascal or Modula. The "High-Level Assembly Language" sticker is not accurate.

Shows you how long its been. The 386 reference was to the shuttle GPCs, and an off-hand salute to you guys on the SSU team being so dedicated to recreating the systems. But to use it for Orbiter . . . is that just a wish or is there some way to do that?

 

[Urwumpe]

Shows you how long its been. The 386 reference was to the shuttle GPCs, and an off-hand salute to you guys on the SSU team being so dedicated to recreating the systems. But to use it for Orbiter . . . is that just a wish or is there some way to do that?

It will stay a wish for a while. I can already implement a System/4Pi CPU accuratly, but the remaining support systems will be guesswork for a long while. And as the original Shuttle Software will not be released anytime soon (but I would like it), it makes no sense doing so.

Additionally, we have already enough problems with our performance, for emulating 5 GPCs, you would need at least a Quadcore to be on the safe side.

So, over the next versions, the GPCs will get implemented with a way to emulate the access of the bus systems and I/O in a similar away as it should appear in the two operating systems of the Shuttle (for example, automatic reading of subsystem data every x * 40 milliseconds). Additionally, the software will be broken down into Micro and Macro cycles, giving a fairly realistic reaction speed for user inputs (not all software reacts every minor cycle, less critical data is updated less often etc).

But for a complete emulation, we would need much more... the I/O Processor would needed to be known better. I have the description of the Shuttle Bus hardware on the other end of the IOP, as seen from the CPU, and many descriptions of a similar IOP from the Skylab computer, but the IOP in the Shuttle has some differences.

The I/O addresses of the Shuttle bus hardware (MDMs, etc) would be needed to be known better as well as the internal protocol used (which seems to be the same for all)

 

[movieman]

However (again, from what I have read) this is now not true in general anymore and whilst the majority of java applications run slower than equivalent native code applications, the difference is negligible (I've heard 2-10% quoted as the norm) and in a lot of cases, this doesn't matter.

I've been hearing those claims for years, but Java still seems much slower than compiled C++ for anything CPU-intensive.

Of course given that most things people do these days aren't particularly CPU-intensive, that means it's fine for many applications; often you're more concerned with development time than performance, so if you can have a Java-based product shipped a couple of months before a C++ based product, it's a good choice. I'm certainly impressed by how much faster Java compiles are than C++.

Also, Java can be significantly more secure than C++ due to pointer checking and the like, though you're then at the mercy of the various JVM security bugs that get reported now and again.

 

[agentgonzo]

Also, Java can be significantly more secure than C++ due to pointer checking and the like, though you're then at the mercy of the various JVM security bugs that get reported now and again.

Java certainly does stop buffer overflow security vulnerabilities, but security flaws can be coded in any language. I'd definitely have a good argument with someone who suggested coding in java on security grounds alone.

 

[cjp]

Platform independence has more to do with the presence of a good compiler, virtual machine and/or interpreter, libraries, and everything else you need, on multiple platforms. Even windows executables are platform independent, if you allow using of the Wine software. Only, some languages, libraries etc. are designed in a way that's more convenient to be used on any platform.

AFAIK Mono (C# for Linux and many other OSes) has a reasonably good virtual machine, but the .NET library implementation is still unfinished. The same is true for Wine: it can run windows executables perfectly, but many of the standard libraries of windows are unfinished in Wine, which sometimes gives bugs. The situation is probably better if you use Java, or if you use C/C++ with only standard libraries and libraries that have been ported to several platforms (and not system calls to the OS itself of course).

I once thought of making a C-to-Brainf#ck compiler, but I stopped when I found out that some other freak was already doing that. Anyway, I don't think Turrican 2 in Brainf#ck would fit in 64k.

 

[Urwumpe]

I've been hearing those claims for years, but Java still seems much slower than compiled C++ for anything CPU-intensive.

That could come from the fact that for most GUI applications, you idle most of the time - unless your GPU is broken and you have to do the whole drawing stuff on the CPU (Like happened to me when my GPU was broken).

 

[Face]

AFAIK Mono (C# for Linux and many other OSes) has a reasonably good virtual machine, but the .NET library implementation is still unfinished. The same is true for Wine: it can run windows executables perfectly, but many of the standard libraries of windows are unfinished in Wine, which sometimes gives bugs. The situation is probably better if you use Java, or if you use C/C++ with only standard libraries and libraries that have been ported to several platforms (and not system calls to the OS itself of course).

All true. It's just that the only system I've used so far in multi-platform ways (C, C++, Java, .NET), that supports networking, threading and user interface all equally well without trouble was the .NET/Mono system. I even tried Wine as compatibility platform coming from the Windows side and Cygwin coming from the *nix side - only having to maintain one code base without thinking too much about the other OS. All those approaches sucked TBH. Surely, I got it to work sooner or later, but it was always a hassle to work with. Even Java. .NET/Mono on the other hand just worked.

For me, that is. For my projects, of course. I can only tell my view of it, and I'm quiet sure this is not the same for all others. Its just... remember that infamous Vista-ad where everyone says wow? Never had this feeling using Vista, mind you, but it is exactly the feeling I had realizing the platform-independence of .NET/Mono (even though I USED Java before). Just like realizing how distributed version control changes your way of collaboration among huge code-bases when all you know is Subversion.

I once thought of making a C-to-Brainf#ck compiler, but I stopped when I found out that some other freak was already doing that. Anyway, I don't think Turrican 2 in Brainf#ck would fit in 64k.

Yeah, there are even freaks making FPGA programs to create CPUs natively understanding Brainf#ck. Scary, to some degree...

regards,
Face