C# and other OOP languages

[miguelvp]

I'm pretty sure most programs run in non changing hardware.

If by "most", you mean "some ambiguous number I've pulled from my exhaust pipe"    Sorry, I couldn't resist.  No offense intended, I'm just skeptical of anyone's guess as to the nature of "most programs".  That seems as nebulous as saying "most webpages are HTML 4 Transitional" or something.  Good luck proving a sample is representative.

Embedded hardware outnumbers webpages or computers and their associated installed programs.
No need to even prove it, you have more lock down hardware running code in your house than any other software. Even your "exhaust pipe" runs embedded software on dedicated hardware

[SirNick]

Y'know... you're probably right, actually.  Contemplating the number of embedded devices is rather mind-boggling.

OK, I take my sarcastic quip back. 

[vvanders]

There's really not a need for non-portable hand optimizations in the types of systems where cache misses hit you hard(dram based, 400+ cycle losses). In those cases you're only optimizing the 10% that's in the domain of the compiler. The rest of it, the way you organize and access data, that's where the real perf gains are to be made.

You clearly don't understand how large organisations (plural) develop and run large applications that must continue to run in the years and decades to come.

I highly recommend watching the Herb Sutter talk I linked previously, he shows quite a few examples where even simple arrays over hashmap/etc end up multiple orders of magnitude faster due to locality of data and prefetching.

Yes, I'm sure that's true for those microbenchmarks. If you want to go down that route, note that Fortran is inherently an array based language, and in these respects it is noticably better than pointer-based languages such as C/C++/Java/C#. More snidely, it sounds as if Sutter has triumphantly re-invented Fortran!

Let me know when you have removed most pointer de-referencing from most C/C++/Java/C# programs, and I'll start to think Sutter has a point that is relevant to general C/C++/Java/C# programs.

If you had watched the full talk you would have seen that he refers to other people's real-world use cases later on. Feel free to dig up Mike Acton or any other other Data Oriented Design enthusiasts. There's many practical, real-world examples that are shipped in many products.

FYI I've got nothing wrong with Fortran, it's just a language that I'm not familiar with and that you won't see a wide a compiler support across the embedded space. I'm just hoping to educate the people who are using C/C++ to use is smarter and better rather than the way "traditional" CS courses tend to teach it. Things like why Radix Sort for normal datasets(for <1000 based on simple keys) is disgustingly faster than any other sorting algorithm, cache usage and all the unintuitive stuff they don't teach you in school.

[VK3DRB]

Here's the way I see it:

Software always has bugs.  Optimization problems can be sneaky, for sure, but hopefully a good test suite will catch a lot of this before the code ever sees the light of day. 

Bugs includes incorrect use of upper and lower case in documentation (a common disability found in engineers), poor alignment of text boxes, inconsistencies in GUI layout, and an illogical state machine.

For critical applications a good test suite includes unit testing, boundary testing, automated functional testing with a test harness, usability testing and of course ad-hoc testing. Ad-hoc testing in my opinion is the most powerful because it discovers unexpected behaviour not identified in the test suite. Ad-hoc testing and usability testing should be given to someone who has minimal knowledge of the software so that there are no prejudices.

It is highly unlikely Apple did any proper usability testing with their iTunes crapware.




 

[tggzzz]

I do wish you would stop making well-reasoned points which are relevant in theory and practice: it is soooo boring.

Software always has bugs.  Optimization problems can be sneaky, for sure, but hopefully a good test suite will catch a lot of this before the code ever sees the light of day.  If not, then maybe they will be found in the wild, investigated, and resolved in whatever way is most appropriate.  Not ideal, perhaps, but realistically that's just part of the software release cycle.

Old engineering maxim: you can't test quality into a product. Unfortunately software-neophytes aren't taught that, to the extent that I've seen too many believe that if the tests are passed then it works.

Test suites are vital, but limited. A particular problem is that each product's test suite almost certainly doesn't address issues w.r.t. integrating the product into a system. But you are probably very keenly aware of that!

In general my attitude is to choose tools that minimise the chance of problems occurring now or later. Yes, I prefer the "bluntest" tool that does the job. If a tool has to be "sharp" I want to see it have adequate handles, guards and shields - so that mistakes by me or others don't hurt too much.

One might say, "But why exacerbate the potential for bugs by continuing to use languages where this is a problem?"  That's a fair point, One.  However, this has to be considered as one of the often many potential drawbacks of any given tool.  Java has dependency issues like a mother, for e.g.  Root help you if you have the wrong JRE.  That will often lead to the same kind of "WTF -- it works fine on my other computer!" problems as optimization flags.  .Net has its share of quirks as well.  This is not a unique dilemma to C. 

Just so. But at least the fault appears early before any damage has been done (cf dangling pointers), is reproducable, and relatively easy to find, and you you can be certain when you have fixed it.

Maybe Fortran runtime environments are perfect though.  I dunno, never used it.

Splutter. If only! I've only written one Fortran program, but I listen to people that have used (and debugged) many large systems (e.g. HPC number crunching) written in different languages. Their opinion is much more valid than mine.

[westfw]

Maybe Fortran runtime environments are perfect though.

Heh.  Shared common areas!  And the things you had to do to deal with text!
The problem is that even within a single "problem", there are multiple sub-problems that are significantly different than one another.  I spent a long time not understanding why OOLs were useful, given that my deep embedded and CLI "problems" seemed equally suited to traditional procedural methods.  And then I looked into writing a window-based application on a desktop.  "Gee, it sure would be nice if there was some way to package up all this initialization data and such into the libraries.  Oh!  That's what those "objects" are good for!"
For a while, companies were designing general purpose languages that were supposed to do everything and anything that any programmer could want.  PL/1 and Ada are the most extreme examples I can think of.  Those didn't work out so well.  The more modern trend is to produce languages aimed at smaller targets.  Which works pretty well until you have flame wars about how some interpreted language is "just fine for systems programming, as long as you run it on a sufficiently powerful platform."

[Howardlong]

Here's an example of .Net ridiculousness. As we all know it has its fair share of security updates. But for some time, each security update required the framework, or whatever it's called these days, to completely re-compile the entire runtime code base.

So, say you're installing the OS, it's not uncommon to have several dozen .Net security updates to apply. Each one needs to recompile the runtime. Again and again. What a crock. And why is it pre-compiling? I thought this stuff was JITted? Nope, because they realised that JITting caused apps to load so slowly that they disposed of that idea and decided to precompile the runtime anyway.

That same recompile happens one or more times on patch Tuesday too.

So why not just distribute the patched code pre-compiled anyway?

Microsoft also claim that the supposed  "background" processes like .Net compilations that go on have no effect on the end user desktop experience, because they run at a low priority. Meantime, the end user's disk cache in well and truly purged. Someone better teach these guys about how disk caching works, or upgrade everyone to SSDs.

[tggzzz]

Here's an example of .Net ridiculousness. As we all know it has its fair share of security updates. But for some time, each security update required the framework, or whatever it's called these days, to completely re-compile the entire runtime code base.

So, say you're installing the OS, it's not uncommon to have several dozen .Net security updates to apply. Each one needs to recompile the runtime. Again and again. What a crock. And why is it pre-compiling? I thought this stuff was JITted? Nope, because they realised that JITting caused apps to load so slowly that they disposed of that idea and decided to precompile the runtime anyway.

The ahead-of-time static analysis and compilation was a very deliberate choice, and is a good choice for resource-constrained devices e.g. small portable devices. Android does something similar.

It also enabled their marketing department to make snide remarks about Java, which was a real threat to MS when .NET was being developed.

So why not just distribute the patched code pre-compiled anyway?

Effective ahead-of-time optimisation requires fitting to the precise machine in terms of cache size, instruction set etc. There are too many combinatorial possibilities for such pre-compilation.

Microsoft also claim that the supposed  "background" processes like .Net compilations that go on have no effect on the end user desktop experience, because they run at a low priority. Meantime, the end user's disk cache in well and truly purged. Someone better teach these guys about how disk caching works, or upgrade everyone to SSDs.

All tool vendors make barely justifyable claims.

[Howardlong]

Effective ahead-of-time optimisation requires fitting to the precise machine in terms of cache size, instruction set etc. There are too many combinatorial possibilities for such pre-compilation.

I assume we're talking about RAM cache... if so I really have a hard time believing that they compile based on one Intel processor's cache to another. It's assuming an awful lot, including what else might be running at the same time. I can understand that they might want to take advantage of a given CPU's instruction set enhancements, although in almost all use cases I doubt it makes much difference from a pre-compiled x86 or x64 binary: even MS only expect a 5% improvement. Perhaps in some DSP scenarios, yes, I can see such a benefit, taking advantage of newer instructions. I'd rather take a predictable and consistent average 5% speed hit to indeterministic behaviour, with those immortal words of the call centre, "Computer's running a bit slow".

All tool vendors make barely justifiable claims.

You got that right!

[tggzzz]

Effective ahead-of-time optimisation requires fitting to the precise machine in terms of cache size, instruction set etc. There are too many combinatorial possibilities for such pre-compilation.

I assume we're talking about RAM cache... if so I really have a hard time believing that they compile based on one Intel processor's cache to another. It's assuming an awful lot, including what else might be running at the same time. I can understand that they might want to take advantage of a given CPU's instruction set enhancements, although in almost all use cases I doubt it makes much difference from a pre-compiled x86 or x64 binary: even MS only expect a 5% improvement. Perhaps in some DSP scenarios, yes, I can see such a benefit, taking advantage of newer instructions. I'd rather take a predictable and consistent average 5% speed hit to indeterministic behaviour, with those immortal words of the call centre, "Computer's running a bit slow".

I was thinking of L1/L2 cache rather than any caching done in "RAM".

For the purpose of this discussion I include "linking" in the compilation process. I can imagine that (in order to try and compete with Java's HotSpot) during installation some highly processor-specific libraries are either statically linked and/or inlined.

Windows 8 requires using the CMPXCHG16B instruction which is not present in all processors. That is an oblique hint that cache and cache access isn't merely a case of different cache sizes - but I don't know all the details.

Windows runs on more than just X86; I don't know about .NET. (The last time I looked at .NET in detail was when Anders Hejlsberg came and gave us a talk about C#/.NET shortly before it was released. Since it was a single-o/s Java-lookalike I decided I wouldn't bother to use it unless it became necessary).

Speed vs predicatability: I'd go for predictability too. But marketeers and benchmarkers wouldn't After all, operations and maintenance a Somebody Else's Problem!

[Howardlong]

Yes, I was trying to distinguish between that and disk cache.

Problem is, any cache is a shared resource: an app, and its compiler, can't make assumptions that it's the only game in town. It can, at a micro-level, determine the best way to compile up, say, a loop, so that it fits into a single cache allocation unit, but beyond that no assumptions should be made.

The project I worked on was written on the original .Net back around 2001 or so when a years worth of Java development was canned and "ported" (yes, that's right, of course it wasn't going to be completely rewritten) to .Net. I still to this day have no idea what they were thinking, but we had Microsofties parachuted in like flies around the proverbial t%rd, some of whom were OK, but most were no better than anyone else who'd read a couple of books. But it turned out it was a whitepaper development, so it had to work, and it was demo'd at one of the Barcelona shindigs, where we had to load up every screen of the app before doing the demo because it was such a sloth. It's still around today, in .Net, but now everythings being ported to.... you guessed it, Java.

Cheers, Howard

[tggzzz]

Yes, I was trying to distinguish between that and disk cache.

Problem is, any cache is a shared resource: an app, and its compiler, can't make assumptions that it's the only game in town. It can, at a micro-level, determine the best way to compile up, say, a loop, so that it fits into a single cache allocation unit, but beyond that no assumptions should be made.

Yes and no. There is a choice as to whether the cache address is the (process+virtual address) or (physical address). One is easier/faster to implement, the other reduces (eliminates?) the ability of one process to evict other processes from the cache.

The project I worked on was written on the original .Net back around 2001 or so when a years worth of Java development was canned and "ported" (yes, that's right, of course it wasn't going to be completely rewritten) to .Net. I still to this day have no idea what they were thinking, but we had Microsofties parachuted in like flies around the proverbial t%rd, some of whom were OK, but most were no better than anyone else who'd read a couple of books. But it turned out it was a whitepaper development, so it had to work, and it was demo'd at one of the Barcelona shindigs, where we had to load up every screen of the app before doing the demo because it was such a sloth. It's still around today, in .Net, but now everythings being ported to.... you guessed it, Java.

Plus ca change, plus c'est la meme chose. Twas ever thus.

[Howardlong]

The same extends in the disk cache arena to long term spindle-bound processes like AV and backups, neither of which should read data in a way that purges cache, but sadly this often doesn't happen.

[Sigmoid]

IMHO C# is 'Java which works for Windows'. Given that many Java programs work very crappy I feared the worse when Google announced they wanted to use Java for Android. Fortunately Google decided to create their own Java engine from scratch which more or less acknowledged my fears.

I'd rephrase that and say that C# is 'Java which works'. Period.

Since the awesome job Novell has done with MONO, C# and its standard libraries have also become a portable programming tool. If I can choose between C# and Java, I definitely go with the first if possible.

With all the idiotic engineering decisions in JAVA, the overall pain in the rear that programming the bloody thing is, Oracle's unscrupulous approach to things (like patent trolling and bundling the runtime with malware), the weird and random incompatibilities between versions, the shit integration on pretty much any platform (not just Windows), and the speed (or lack thereof), and the memory usage, I'd say C# is far superior from both an end user and developer perspective.

[SirNick]

On the "old PC" thread, someone referred to iOS / OS X development, and that led me to go back and look up Objective C again.  Turns out Apple is pushing for a change to Swift now.  Anyone looked into that?  Would it have relevance outside of Apple's world?  From a few syntax snippets that I saw it looked C-like enough to be familiar and comfortable, while providing OOP and side-stepping some of the main hurdles with large C applications (like having so much to do with pointers.)

[tggzzz]

On the "old PC" thread, someone referred to iOS / OS X development, and that led me to go back and look up Objective C again.  Turns out Apple is pushing for a change to Swift now.  Anyone looked into that?  Would it have relevance outside of Apple's world?  From a few syntax snippets that I saw it looked C-like enough to be familiar and comfortable, while providing OOP and side-stepping some of the main hurdles with large C applications (like having so much to do with pointers.)

As far as I can tell it is constrained to be syntatic sugar, since it has to be completely compatible with Objective-C. Syntatic sugar can be nice and convenient, but won't enable new capabilities (although it may make enable more people to write code and/or do it faster).

in its current incarnation, it will have even less relevance outside Apple than C# has outside MicroSoft.

[SirNick]

Huh.  I thought it was just intended to be linkable with Obj-C.  That's too bad.

[theatrus]

Swift has to be interoperable with the ObjC runtime, less so the language. For example, it is impossible to inherit from a Swift class in ObjectiveC (though it is possible to bridge Objective C to Swift).

For a 1.0 language, with a strong compatibility requirement with ObjC, they've done very well.

[tggzzz]

Swift has to be interoperable with the ObjC runtime, less so the language. For example, it is impossible to inherit from a Swift class in ObjectiveC (though it is possible to bridge Objective C to Swift).

Does it make any sense to conceive of an Objective-C class inheriting from a Swift class? I would accept significant limitations on what's in the Objective-C class.

For a 1.0 language, with a strong compatibility requirement with ObjC, they've done very well.

That's my impression too. (Much better than C++ and C!)

[theatrus]

Does it make any sense to conceive of an Objective-C class inheriting from a Swift class? I would accept significant limitations on what's in the Objective-C class.

If someone writes a library / view controller / etc in Swift, yet your normal application workflow is still ObjC? Not many would fall in that camp, but it is conceivable. Using any Swift also restricts you to the 8.0 SDK (unsure on the OS X side).