C# Implementation of fpaq0p_sh and Performance Analysis

[osmanturan]

Hi everyone,
Due to my job, I can't actively participate the community. We're working hard on .NET technologies and as a result I want to test a known compressor performance in .NET.

The motivation points are:
- Upcoming Windows 8 also targets ARM processors as well as x86/x64 platform and most likely won't support x86/x64 emulation on ARM. So, .NET is only viable solution for cross-platform Windows x86/x64 vs ARM development.
- VM architecture usage is increasing.
- .NET's strongly typed nature eliminates preliminary bugs (you can't even assign an "int" type variable to "short int" type variable without an error like you could do in C/C++). But, garbage collection could be both bottleneck and improvement for performance-wise.
- CLR core libraries are same on both Microsoft .NET and Mono. And they enable developers to write archivers/compressors easily (you don't need to worry about unicode encoding, rewriting simple data structures etc).

So, only question which data compression community is really concerned is "performance". I've implemented fpaq0p_sh (thanks to Shelwien) in C#. Instead of direct implementation, I've intentionally rewritten in object-oriented manner (I've used some interfaces, common classes, exception handling etc). This way, the implementation can be considered as a simulation of a ordinal C# guy design pattern.

Anyway, I've made some benchmark on my laptop (i7 740QM 1.8 GHz, 8 GiB RAM, 7200 RPM HDD) for ENWIK8.

No code has to be inserted here.

IMO, test results actually do not reflect "Hey, C# is faster than C/C++!". I know, Shelwien can come up a performance optimized compiled version of his rc_v0. The difference is probably due to optimized I/O of CLR core libraries. But, my point in this test: ".NET performance is not that bad for compression".

All sources and binaries are included in the attachment. You need .NET Framework 2.0 at least to run it.

[Shelwien]

Uh, Osman, please also test exes from
http://nishi.dreamhosters.com/u/newbrc_2.rar
http://nishi.dreamhosters.com/u/fpaq0pv4b4.rar
The exes in rc_v0 are size-optimized, so its not even a good representation of MSC's performance of actual rc_v0.

[osmanturan]

Ok ok... You got me I did not know they were size optimized, instead I thought they are just regular builds. Here is the test results:

No code has to be inserted here.
I didn't even bother to test all programs and measure decompression time

[Piotr Tarsa]

I can't see why C/ C++ has to be faster than any other language (not considering hand made assembly of course). Speed depends mainly on compiler. CLR, JVM or any other dynamically profiling execution environment can achieve much greater speeds than code that is not reoptimized on the fly. Probably if you profile that C++ code on enwik8 compression then you'll obtain speed better than that of C# code.

I'll try to prepare some program. Hopefully there will be some dynamic profiling

[osmanturan]

Piotr, I was sure you would drop a comment in this thread If you have free time, I'll glad to see a Java implementation of fpaq0p_sh. Mind you?

[Shelwien]

> So, .NET is only viable solution for cross-platform Windows x86/x64
> vs ARM development.

Well, there's also java and recompiled C/C++.

> - VM architecture usage is increasing.

Fortunately at least iOS apps are native code.
So I really hope that all VM-based competition would just die.

> - .NET's strongly typed nature eliminates preliminary bugs

I really doubt that.
Imho it just turns programming into an annoying process.
When the compiler forces you to put an explicit type conversion
somewhere, it doesn't mean that you would really think about it,
instead of cursing the compiler and typing in the conversion operator.

> And they enable developers to write archivers/compressors easily

Such libraries are good for scripting, but very bad for real apps.
You just can't post .NET/java binaries on a forum, because people
would complain that they don't work, and with the whole framework it
would be too big.

> (you don't need to worry about unicode encoding, rewriting simple
> data structures etc).

Actually you do (at least in compression case).
Automatic structure serialization is very convenient...
but only while you don't want to mess with the binary representation
of serialized structures (including unicode strings).

So if you want to make a new binary format (archive or anything),
it means that you can't rely on the library for converting stuff
from internal representations to binary blobs.

In which case all VM languages suddenly become very bothersome,
so people keep inventing redundant stuff like XML and JSON instead.

> So, only question which data compression community is really
> concerned is "performance".

Not really. Try creating a 1900M hashtable on XP 32-bit with .NET
and you'll see.

Though if C# would let you beat paq8 or something like that,
I'd be happy anyway.

> The difference is probably due to optimized I/O of CLR core libraries.

In fact I've seen a few similar results with java before.
I'd really like to know whether some part of framework can remain
after supposed program's termination (like to flush the write cache
and clean up).
Maybe I should try writing a timer which would track when the file lock is released...

> ".NET performance is not that bad for compression".

Yes, just about 2x slower or so, plus memory overhead which reduces the dictionary size.

Also its not really a language program, but a programming style problem.
However, C#/java don't support the style which produces the fastest programs.
Same applies to mainstream C++ though.

> Speed depends mainly on compiler

Yes, but JIT compilers are still worse than gcc/intelc.
Maybe mostly because they can't afford to think for a few hours
before running an app, but still.

> I can't see why C/ C++ has to be faster than any other language

Because languages based on concepts not supported by hardware are
inherently inefficent.
For example, x86 cpus don't have any support for text strings -
you can't write a function which takes two abstract strings and returns
their concatenation in asm.

So a C/C++ program written in style which doesn't rely on alien concepts
like dynamic memory or exceptions can be faster and more stable/portable than
a similar C#/java program... or a C++ program using STL.

[osmanturan]

> So, .NET is only viable solution for cross-platform Windows x86/x64
> vs ARM development.

Well, there's also java and recompiled C/C++.

Yes. But, .NET is becoming a part of Windows system. Just think about a program which can be just downloaded by a user and it can be run both user's desktop and tablet without installing any third party program (like Java VM). Also, did I even mentioned another Windows API? WinRT?

> - VM architecture usage is increasing.

Fortunately at least iOS apps are native code.
So I really hope that all VM-based competition would just die.

Yep. iPhone's main strong point is that. It uses native codes as opposed to Android's Dalvik VM. So, iPhone 4S with ~800 MHz Dual Core ARM can be comparable with Galaxy S2 with 1.2 GHz Dual Core ARM which is considered one of the fastest Android phone. But, I'm not against neither VM or native. Because, they have their places to be used. As to "kill'em all VM" idea, I think we need it. I was against as you until I've stepped into it. Because, increasing cross-platform demand increases productivity. On the other hand, I agree developers are getting lazy.

> - .NET's strongly typed nature eliminates preliminary bugs

I really doubt that.
Imho it just turns programming into an annoying process.
When the compiler forces you to put an explicit type conversion
somewhere, it doesn't mean that you would really think about it,
instead of cursing the compiler and typing in the conversion operator.

These remind me my earlier times of VM world. I was quickly "fixing" those errors just like you mentioned. But, I'm getting used to it. So, this turns into careful coding behaviour. And I'm no longer applying such fixes usually.

> And they enable developers to write archivers/compressors easily

Such libraries are good for scripting, but very bad for real apps.
You just can't post .NET/java binaries on a forum, because people
would complain that they don't work, and with the whole framework it
would be too big.

If you're still working on default installation of XP, you can't run it, I agree. But, as I said before, .NET becomes a Windows API. So, I don't have such worries any more. And it will be vanish more and more by the time when Windows 8 emerged. Because, I expect most of devices will be touch enable (regular monitors, notebooks etc). So, most people want to upgrade their systems. As a side-effect, they will have .NET enabled systems. Just think back about DirectX days. We're forced to install DirectX. But, now it's just a part of Windows. Some time ago, we needed upgrades but it's vanished by new hardware model which is introduced with DX 10.

> (you don't need to worry about unicode encoding, rewriting simple
> data structures etc).

Actually you do (at least in compression case).
Automatic structure serialization is very convenient...
but only while you don't want to mess with the binary representation
of serialized structures (including unicode strings).

So if you want to make a new binary format (archive or anything),
it means that you can't rely on the library for converting stuff
from internal representations to binary blobs.

In which case all VM languages suddenly become very bothersome,
so people keep inventing redundant stuff like XML and JSON instead.

Core libraries is really well-designed. They can be used both "lazy" developers and "pushing-edge" developers. So, complicated archive formats is not really a mess. Also, .NET has even serialization methods for both binary, XML, JSON and even custom formats. So, it makes even easier.

> So, only question which data compression community is really
> concerned is "performance".

Not really. Try creating a 1900M hashtable on XP 32-bit with .NET
and you'll see.

Yeah. You're right at that point. But, my point is not you can do anything with C# like you do in C/C++.

Though if C# would let you beat paq8 or something like that,
I'd be happy anyway.

I'm not that optimistic. But, I'm considering .NET or Java are not that bad for production.

> The difference is probably due to optimized I/O of CLR core libraries.

In fact I've seen a few similar results with java before.
I'd really like to know whether some part of framework can remain
after supposed program's termination (like to flush the write cache
and clean up).
Maybe I should try writing a timer which would track when the file lock is released...

I don't know Java internals, but, I know some internals of .NET. Because, .NET Framework's source is released by Microsoft after emerging decompilers for CLR. As to your question, .NET uses native Windows API. So, there is no "after termination". Here is the proof:

http://typedescriptor.net/name/members/2499A226E9C8E7034D5D8F9DC91F5F00-System.IO.FileStream.WriteFileNative(SafeFileHandl e,Byte[],Int32,Int32,NativeOverlapped*,Int32&)

You can trace methods from Dispose method which is explicitly called in my code at the end of "using { }" block for created file streams. Note that, I didn't used async I/O intentionally.

http://typedescriptor.net/browse/typ....IO.FileStream

> ".NET performance is not that bad for compression".

Yes, just about 2x slower or so, plus memory overhead which reduces the dictionary size.

Also its not really a language program, but a programming style problem.
However, C#/java don't support the style which produces the fastest programs.
Same applies to mainstream C++ though.

Yes. They have different strong sides. I really like .NET portability and language extensibility. For example, LINQ is a great way to deal with big data structures. They are essentially lambda enabled queries which are "lazy executed" (defered as pointed in Microsoft documents). So, you can compile them on the fly for your favorite data structure. For example, few days ago I've implemented Linq to Google Analytics for our CMS product for both increasing our productivity and reducing our bandwidth.

As to C++ side, I'm really happy with emerging C++11 features. Especially lambda functions and "enum" improvements.

> Speed depends mainly on compiler

Yes, but JIT compilers are still worse than gcc/intelc.
Maybe mostly because they can't afford to think for a few hours
before running an app, but still.

LLVM is considered one of the fastest online native code generator and Mono uses it as back-end. But, I've seen some tests that Microsoft CLR outperforms Mono CLR mostly. Considering LLVM is financed by Apple, one could expect to see that it won't take too long to reach nearby of GCC/IntelC. On the other hand, I'm not claiming they will surpass GCC/IntelC with a huge margin.

> I can't see why C/ C++ has to be faster than any other language

Because languages based on concepts not supported by hardware are
inherently inefficent.
For example, x86 cpus don't have any support for text strings -
you can't write a function which takes two abstract strings and returns
their concatenation in asm.

So a C/C++ program written in style which doesn't rely on alien concepts
like dynamic memory or exceptions can be faster and more stable/portable than
a similar C#/java program... or a C++ program using STL.

"Alien" functions can be just placed in native asm function at JIT level. But, I agree you can't do micro-optimizations just like you do in C/C++. I think, this is a price of "portability".

As a conclusion, I'm not against neither native and VM-based codes. Just they have their places. As to compression side, I still think they can be used on avarage compression algorithms. Not like memory and performance hunger state-of-art applications (like paq8 or our pushing-edge experimental compressors).

[Piotr Tarsa]

Yes, but JIT compilers are still worse than gcc/intelc.
Maybe mostly because they can't afford to think for a few hours
before running an app, but still.

I think that they are slower mostly because they are compiling at each VM invocation. I wonder if Java guys will ever implement something like caching binaries or at least profiling data. JVM is running in interpreter mode for rarely executed code (rarely here is 100 000 invocations of instructions, so if there is a loop that is iterated million times then the first one hundred thousand iterations will run in interpreter mode) so I think JVM is spending too much time in interpreter mode to make comparisons fair now.

Because languages based on concepts not supported by hardware are
inherently inefficent.
For example, x86 cpus don't have any support for text strings -
you can't write a function which takes two abstract strings and returns
their concatenation in asm.

So in C you do not concatenate strings? That's interesting. BTW actually there's support for strings in hardware: http://www.strchr.com/strcmp_and_strlen_using_sse_4.2

So a C/C++ program written in style which doesn't rely on alien concepts
like dynamic memory or exceptions can be faster and more stable/portable than
a similar C#/java program... or a C++ program using STL.

Well, almost all CPUs are tailored for executing native code, ie there are complicated memory management units built into them and which are useless for managed platforms. Java would run happily without hardware memory protection, I think that even Java would be happy without hardware memory addresses translation (you have did tests for accessing memory pages that aren't in TLB, imagine there's no TLB and no translation penalty) and with cooperative multitasking (so no hardware interrupts or state saving mechanisms would be needed, I think that even something like mixing code from two threads into one code stream would be possible, that would be equal to software based Hyper-Threading).
Exceptions are exceptions. They shouldn't be used to control program flow. They are throwed rarely so they do not impact performance much.

When it comes to memory allocation then garbage collected implementations win. Look at: http://shootout.alioth.debian.org/u6...st=binarytrees Top C/ C++ entries are using object pools so the comparison is not fair for me. When we consider only allocation through standard mechanisms then scores are as follows:
Java multi 17.97 / 8.19
Java single 14.05 / 11.58
C multi 70.50 / 18.67
C single 33.84 / 33.87
C++ single 35.55 / 35.59
Bear in mind that there's hardware MMU that of course C/ C++ takes advantage of.


I have made somewhat flawed examples of programs in C++ and Java that have different performance rations depending on input.
Java: http://pastebin.com/d1m3xsts
C++: http://pastebin.com/VjD0Hb7r

Timings for input (0 2):
Java: 6722
C++: 7230
Timings for input (1 2):
Java: 8449
C++: 7050

Ubuntu 11.10 64-bit, OpenJDK 1.7, GCC 4.6.1 -O2

Piotr, I was sure you would drop a comment in this thread If you have free time, I'll glad to see a Java implementation of fpaq0p_sh. Mind you?

Are you sure? Java doesn't have unsigned integer types (sigh) so code would be messy. Anyway, I've implemented already an arithmetic coder in Java in my jTarsaLZP program. You can find it on this forum.

[Piotr Tarsa]

BTW I've compared Java and assembly versions of my TarsaLZP program on fp.log file. Java program scored about 5.2 - 5.7s when compressing, while hand-optimized assembly (MMX used) program through Wine scored about 4.2 - 4.3s. Not so dramatic difference and remember that in Java there is a lot of mess because of lack of unsigned types.

Edit:
I'll do measurement on Windows as the small performance gap looks suspicious.

Edit:
I was right. On Windows assembly version scores about 3.1s, so there's certainly room for improvements for JVM.

[Sportman]

When I checked the .NET project, I saw the compile setting where not optimal, so I did some tests without changing the code:

Input: 159,234,048 bytes type db
Output: 109,139,861 bytes .net 4 opt comp

67.047 sec. .net 4 original source settings
66.828 sec. .net 2 original source settings
30.506 sec. fpaq0p_sh.exe
22.406 sec. rc2f
20.138 sec. .net 2 optimized compile settings
19.241 sec. original fpaq0p_sh_cs.exe
18.956 sec. .net 4 optimized compile settings
11.143 sec. o0rc_1
11.109 sec. o0rc
10.858 sec. o0rc_2
10.811 sec. o0rc (2)
7.175 sec. rc2d
6.083 sec. rc2e

[Shelwien]

> Yes. But, .NET is becoming a part of Windows system.

http://en.wikipedia.org/wiki/.NET_Framework#History

Its "becoming" for more than 10 years already.
And they can't even freeze the core framework / language syntax
for a few years and let it spread.

> Just think about a program which can be just downloaded by a user
> and it can be run both user's desktop and tablet without installing
> any third party program (like Java VM).

1. That likely won't happen. I mean, you can't run a phone app written in java
on a desktop PC.

2. I really doubt that MS tablets or anything would ever become popular.

3. Windows 8 getting installed on a large share of desktop computers would also
likely take quite a few years.
And during these years, you'd keep forcing users to download 100MB frameworks
along with your app.

> But, I'm not against neither VM or native. Because, they have their
> places to be used.

They don't. Because you can run a VM inside your app on a native
platform, if you want, but a platform based on VM won't let you.

> As to "kill'em all VM" idea, I think we need it.

Well, and I think we don't, but not that we can do anything about it.
In fact its quite possible that the current VM fashion reduces
the competition for me, because most C#/java/python developers
won't ever be able to understand how a computer works, so maybe
I should be grateful for it.

> I was against as you until I've stepped into it.
> Because, increasing cross-platform demand increases productivity.

It doesn't imho.
Script languages only make it easy to write scripts,
but any algorithms not directly supported by language syntax
actually become much harder to implement and maintain.

> These remind me my earlier times of VM world. I was quickly "fixing"
> those errors just like you mentioned. But, I'm getting used to it.
> So, this turns into careful coding behaviour. And I'm no longer
> applying such fixes usually.

I suppose you just stop using short ints, because its annoying,
and corresponding fields in your data structures just take 2x more
memory than they need forever since you "got used".

> If you're still working on default installation of XP, you can't run
> it, I agree. But, as I said before, .NET becomes a Windows API. So,
> I don't have such worries any more. And it will be vanish more and
> more by the time when Windows 8 emerged.

I suppose win8 .NET apps won't work even on win7,
so you'd have to wait like 10 years to stop caring about that -
or more if they'd keep screwing it up.

> Because, I expect most of devices will be touch enable (regular
> monitors, notebooks etc).

Touchscreens would be always more expensive than normal ones.
Also normal keyboard and mouse would be always more convenient
than a touchscreen, except for cases where you just can't use them.

Even if touchscreens were perfect and actually worked like they're
supposed to, they'd simply get dirty and that's already inconvenient.

> So, most people want to upgrade their systems. As a side-effect,
> they will have .NET enabled systems. Just think back about DirectX
> days. We're forced to install DirectX.

Yes, and we're still forced to install directX, because there're
newer versions than the one preinstalled with the OS.

> Core libraries is really well-designed. They can be used both "lazy"
> developers and "pushing-edge" developers. So, complicated archive
> formats is not really a mess. Also, .NET has even serialization
> methods for both binary, XML, JSON and even custom formats.

Yes, but is there any guarantee that the serialization format
never changes in different framework versions?
If not, you have to do it manually.
Which is afaik more complicated than writing it in C.

> I'm not that optimistic.

You can start by translating paq8px to C#.
Its probably possible to write some scripts to simplify that.
And I don't think that paq uses anything which doesn't have
a direct equivalent in C#.

> But, I'm considering .NET or Java are not that bad for production.

Depending on the task.
But then again, they may be beaten by javascript in the end.
And such platforms are only applicable for boring tasks anyway.

> So, there is no "after termination".

Uh, there's at least some where the VM quits after
the end of your program.
Although I guess we can add a WriteFile call at the
end of your coder and check whether it really would
write to the end of file and won't slow down the program.

> I'm not claiming they will surpass GCC/IntelC with a huge margin.

As I said, the circumstances are simply too different.
A big C++ project would take hours to compile, and
VM loader would never be able to afford that.

Though there're also issues of vectorization - even
gcc didn't quite catch up to intelc in that sense,
and I never heard about JIT engines using it.

> "Alien" functions can be just placed in native asm function at JIT level.

By "alien" I meant language concepts without explicit hardware support,
like variable-size arrays.

And yes, they can be simulated somehow, but its not likely that compilers
would be ever smart enough to automatically refactor high-level strings
to static arrays or anything similar.

And simulated features would be always slower than real hardware.

Btw, x86 hardware has quite a few features which are not used even
by C/C++ compilers, which is unfortunate.

> As a conclusion, I'm not against neither native and VM-based codes.
> Just they have their places.

Sure. Script languages with their supporting VMs and frameworks
are used for scripting, and plain C is used to implement
non-trivial algorithms, because there's no alternative currently.

> As to compression side, I still think they can be used on average
> compression algorithms.

Imho this is not true.
I'd expect C#/java LZ implementations to be much slower than
C/C++ equivalents. A rangecoder simply already has too many
instructions per input byte from the start.

> Not like memory and performance hunger state-of-art applications
> (like paq8 or our pushing-edge experimental compressors).

And I think this is where C#/java are more likely to be of some use -
with x64, the memory overhead doesn't matter so much, and paq8 is
already slow anyway.

Although I guess parameter optimization may be an issue
(as it is with paq.

[Shelwien]

> So in C you do not concatenate strings? That's interesting.

Thanks for the link, and there're no strings in C.

In C, to concatenate strings stored in specific memory locations
using specific layout (asciiz or length-prefixed) you have
to allocate more memory, and then store the strings there.

But you also can write the bytes of the 2nd string directly
after bytes of the first string.

Which is completely different from a performance p.o.v.
(and portability, because the same memory API isn't available
everywhere).

That's not strings, because you have to manually manage
their locations and lengths.

But on other hand, that's compatible with the actual hardware.

While with strings supported by language,
you can just write s1+s2 without worrying about anything else (at first).

But then you'd eventually hit some implicit limits
(like max length of a string is 2G; or garbage collector
suddenly freezing up your app after a few millions of
string concatenations)
and spend the rest of your life trying to implement
a workaround.

[Shelwien]

> imagine there's no TLB and no translation penalty

TLB is not used in "real mode", so that option is actually available.

> and with cooperative multitasking

Don't forget multiple cores etc.
Also interrupts are kinda a good part of cooperative multitasking.

> (so no hardware interrupts or state saving mechanisms would be
> needed, I think that even something like mixing code from two
> threads into one code stream would be possible, that would be equal
> to software based Hyper-Threading).

That's possible with C too (using LLVM or something), its also
kinda a high-level language anyway.
But hardware multitasking is better, and software simulations
are inefficient.

> Exceptions are exceptions. They shouldn't be used to control program
> flow. They are throwed rarely so they do not impact performance much.

Unfortunately exceptions need supporting code everywhere.
Also while they may not affect the program's speed directly,
but they do affect program's architecture (handle ptr==0 here,
or handle an exception somewhere higher up).

> When it comes to memory allocation then garbage collected implementations win.

Yes, but in C/C++ its a useful option, while in java/C# its unavoidable.

[m^2]

Upcoming Windows 8 also targets ARM processors as well as x86/x64 platform and most likely won't support x86/x64 emulation on ARM. So, .NET is only viable solution for cross-platform Windows x86/x64 vs ARM development.

Uhm. You seem to forget about C. And C++. And dozens of other languages that can be compiled for ARM or interpreted on it.

So, only question which data compression community is really concerned is "performance".

No, there are also portability concerns. Usually, porting a codec to a new platform is easy. Porting Mono is not. Though a codec may need porting to even work on Mono too.

Yes. But, .NET is becoming a part of Windows system. Just think about a program which can be just downloaded by a user and it can be run both user's desktop and tablet without installing any third party program (like Java VM). Also, did I even mentioned another Windows API? WinRT?

.NET programs can't be just installed and work on most desktops, according to
https://marketshare.hitslink.com/ope...10&qpcustomd=0
Not sure if the figure is accurate, but there's little doubt that for at least a couple of years to come your dream of just installing your app won't come true.

They have different strong sides. I really like .NET portability and language extensibility. For example, LINQ is a great way to deal with big data structures. They are essentially lambda enabled queries which are "lazy executed" (defered as pointed in Microsoft documents).

It's a bit OT, but that's my main illustration of what I hate in the .NET ecosystem in general. It's a huge mess. WTF did they think when making lambda expressions lazy? It's useful for LINQ, but WTF does LINQ have in common with lambda expressions except that they were developed at the same time?
In .NET for every rule there are multiple poorly documented exceptions and it drives me nuts.

1. That likely won't happen. I mean, you can't run a phone app written in java
on a desktop PC.

There are talks of merging Java ME and SE. So it's likely that it will be possible in not too distant future.

They don't. Because you can run a VM inside your app on a native
platform, if you want, but a platform based on VM won't let you.

So? VM offers fairly high level of binary compatibility. Sun invented JVM, so their platform, which was too small for most devs to care about, got more software. So for Sun it made sense. For devs, this was a much smaller advantage, if Java was compiled with the same level of language portability, they could recompile it for their target platforms. Still, Java offered many things that were not related to portability like a rich standard library, so the deal made sense for many devs as well as for Sun. And for vendors that were in a similar situation to Sun's - especially IBM - too.
When it comes to MS...I don't really see the point of VM other then "Look, it's a Java, just ours"....Well, there are some tiny advantages like x86/x86-64 compatibility that MS screwed up, but it's not a problem for .NET apps or Windows CE, but that's, well, tiny.

Script languages only make it easy to write scripts,
but any algorithms not directly supported by language syntax
actually become much harder to implement and maintain.

I don't agree with you here. And actually algorithms are a major selling point for Python - because in quite a few cases you can use the time saved all around the app to implement smarter algorithms then you would in C and get overall better performance with the same investment.

As I said, the circumstances are simply too different.
A big C++ project would take hours to compile, and
VM loader would never be able to afford that.

I don't claim to be an expert here, but I've read that there are hugely diminishing results with more CPU power investment, so while it's true that they can't get as far as AOT compilers, they can get very close and have the advantage of having a profile. Even when it comes to performance-sensitive code, most devs don't use profiling and a profile generated at runtime is the most accurate one that you can get anyway.
And when it comes to time spent, VMs are in the advantaged position that they optimise only what's worth optimising.


Also, Osmanturan, when you're talking about .NET performance and portability in a single post, please include Mono benchmarks too.

[osmanturan]

I think that they are slower mostly because they are compiling at each VM invocation...

.NET (at least for ASP.NET case) is not compiled for every single invocation. There is a "shadow copy" folder which consists of compiled version of invoked .NET programs. And CLR responsible for recompiling when needed.

Are you sure? Java doesn't have unsigned integer types (sigh) so code would be messy. Anyway, I've implemented already an arithmetic coder in Java in my jTarsaLZP program. You can find it on this forum.

Well... I don't have any practical background with Java. But, I sometimes translate some codes from Java to other languages manually. But, I never realized that such restriction When I think, it's no wonder considering Java's age.

When I checked the .NET project, I saw the compile setting where not optimal...

I've intentionally used .NET 2.0, so most of people can run it. Seems .NET 4's compiler is better in terms of speed.

Its "becoming" for more than 10 years already. And they can't even freeze the core framework / language syntax for a few years and let it spread.

I mainly compare these days with DirectX days. Because, they are essentially not very different. Until DX 5, DX itself was not a good platform for me. Considering even today's .NET Framework 4.0's features were planned even before it's first release (back to 2002), there'll be a better release series in near future.

1. That likely won't happen. I mean, you can't run a phone app written in java on a desktop PC.

Actually you can run it. Only opposite is not true.

2. I really doubt that MS tablets or anything would ever become popular.

I really doubt that. For example, iPad became used by most developers today (well at least for web development with remote desktop). I expect to see Win8 tablets become more popular.

3. Windows 8 getting installed on a large share of desktop computers would also likely take quite a few years.

Yeah. I agree. That's my main point actually. .NET was not a ready for a production last years, it's doubtful even today. But, a production takes already quite time. So, when the product is ready, this is more likely .NET already installed in every single windows copy.

And during these years, you'd keep forcing users to download 100MB frameworks along with your app.

Well, actually 41 MiB for .NET 4 if you don't have an ancient windows copy. http://www.microsoft.com/download/en....aspx?id=24872

They don't. Because you can run a VM inside your app on a native platform, if you want, but a platform based on VM won't let you.

.NET have dynamic code generation. So, you can even make your own VM on top of your .NET program. For example, here is a sample which compiles JavaScript into .NET IL on-the-fly. It's not state of art in performance-wise but it's something IMO. http://jurassic.codeplex.com/

...because most C#/java/python developers won't ever be able to understand how a computer works...

Yeah That's a hot topic in both .NET and Java developers and I've read several blogs about "naive" programmers' job interviews

I suppose you just stop using short ints, because its annoying

Not really

I suppose win8 .NET apps won't work even on win7,...

It's up to developer. If you target a higher framework version than needed, then you are right (win8 has .NET 4.5 and Win7 has .NET 3.5). But, most of time .NET 3.5 is really sufficient (our commercial products are entirely in .NET 3.5). It's same thing when you enable AVX optimizations for a C/C++ applications even you don't really need it.

Touchscreens would be always more expensive than normal ones...

You're thinking as a developer not a regular user. I agree, we need keyboard and mouse. But, end users don't. They like fancy applications and devices At least it's true for my clients.

Yes, and we're still forced to install directX, because there're newer versions than the one preinstalled with the OS.

After DirectX 10, hardware model has changed. You really don't need to upgrade your DirectX version if you have DirectX 10+ supported graphics card. Because, specification are frozen for each version and distinct hardwares support distinct DirectX version.

Yes, but is there any guarantee that the serialization format never changes in different framework versions? If not, you have to do it manually. Which is afaik more complicated than writing it in C.

Yes, there is. As to manual serialization, it's actually not really manual. Because, you have a high-level control over serializations. You can even implement your serialization engine easily for your existed objects without changing anything. I've done it several times.

You can start by translating paq8px to C#. Its probably possible to write some scripts to simplify that...

Sigh... It's a lot of work. But, at least there is C++.NET compiler which can be considered as a quick hack. Actually C++.NET is not a prefered way for .NET.

Depending on the task. But then again, they may be beaten by javascript in the end. And such platforms are only applicable for boring tasks anyway.

Yeah. You're right. Here's a out-of-topic Javascript PC emulator with running Linux kernel and C compiler from QEMU guy. http://bellard.org/jslinux/

Uh, there's at least some where the VM quits after the end of your program. Although I guess we can add a WriteFile call at the end of your coder and check whether it really would write to the end of file and won't slow down the program.

There is no "VM quits after program termination" for CLR. Because, CLR is just a system part. As to native Win32 APIs, you can still write them in .NET applications if you really want. More over you can even call COM objects just like you do in C/C++.

Though there're also issues of vectorization - even gcc didn't quite catch up to intelc in that sense, and I never heard about JIT engines using it.

Well, here it's: http://www.jatovm.org/

but its not likely that compilers would be ever smart enough to automatically refactor high-level strings to static arrays or anything similar.

Actually, CLR string class is static array. If you want to increase string concatenation performance you can use StringBuilder class which optimized especially for this task.

Uhm. You seem to forget about C. And C++...

Yeah...You can always "recompile" any native code to any platform if supported by the compiler. But, my point is different. An executable for both x86/x64 and ARM. That's not possible for Windows 8 case. As to interpreting, as I said it won't be supported by Windows 8.

Usually, porting a codec to a new platform is easy.

I was talking about upcoming Windows 8 versions. I don't know too much about Mono side. But, AFAIK as long as you use some standart CLR library, your .NET app is portable between both Microsoft CLR and Mono CLR. And today, Mono is claimed to be run on even Android phones.

.NET programs can't be just installed and work on most desktops, according to...

I've read several sources with "almost" reliable proofs about that XP usage. Claims are about mostly due to China's usage for pirated windows. So, I'm hoping it will be end in near future.

It's a bit OT, but that's my main illustration of what I hate in the .NET ecosystem in general. It's a huge mess. WTF did they think when making lambda expressions lazy? It's useful for LINQ, but WTF does LINQ have in common with lambda expressions except that they were developed at the same time?

Lambda functions actually are part of system, and LINQ is both language and core library extension. So, they are essentially different. With LINQ you have expression trees (lambda functions are considered as a expression node as well), and you can compile those expression trees into your favorite query langugage such as SQL, Google Analytics, Amazon Book Search, Google Image Search etc.

In .NET for every rule there are multiple poorly documented exceptions and it drives me nuts.

I usually look at MSDN. If it's not enough, I look decompiled output of corresponding method with online or offline tools.

I don't really see the point of VM other then "Look, it's a Java, just ours"...

I think, they are different. As to .NET, it's something like new alternative Win32 API for me. And it was really needed IMO for especially web development and some automated tasks. For example, with IIS 7, you have full control over web traffic in your web application. Because, .NET is simply integrated into IIS 7 as a pipeline stage. You can easily change pipeline behaviour with .NET. But, that was not easy for old days. I remember that I was writing IIS ISAPI libraries. I have to write tons of code for just a simple task. Not to mentioned I have to restart whole web server service just for me.

so while it's true that they can't get as far as AOT compilers, they can get very close and have the advantage of having a profile.

Did I mention that some ARM processors have Java acceleration mode? Those ARM processors even used by lots of smart phones today and AFAIK Android has benefit that feature already.

Also, Osmanturan, when you're talking about .NET performance and portability in a single post, please include Mono benchmarks too.

I don't have a ready-to-go Mono environment. Sorry.

[m^2]

Yeah...You can always "recompile" any native code to any platform if supported by the compiler. But, my point is different. An executable for both x86/x64 and ARM. That's not possible for Windows 8 case. As to interpreting, as I said it won't be supported by Windows 8.

Well, I don't regard binary compatibility as a significant thing, I find recompilation to be cheap. But fine, it still doesn't make .NET significantly privileged, there are numerous interpreted languages too.
I wonder whether there will be Java on them and I expect that some Open Sourcers will do it.

I was talking about upcoming Windows 8 versions. I don't know too much about Mono side. But, AFAIK as long as you use some standart CLR library, your .NET app is portable between both Microsoft CLR and Mono CLR. And today, Mono is claimed to be run on even Android phones.

Last time I checked there were many tiny incompatibilities and that big apps rarely worked. But I don't follow Mono, so this might be incorrect now.

I've read several sources with "almost" reliable proofs about that XP usage. Claims are about mostly due to China's usage for pirated windows. So, I'm hoping it will be end in near future.

In my very limited experience, XP is a major platform, about as big as W7+Vista together....and with usage roughly constant over last year or so. So it doesn't match what the site said, but doesn't suggest that XP is going away either. And I don't even live close to China.
It surely will go away at some point, but I don't see that point at all, it's too distant for me to make predictions.

Lambda functions actually are part of system, and LINQ is both language and core library extension. So, they are essentially different. With LINQ you have expression trees (lambda functions are considered as a expression node as well), and you can compile those expression trees into your favorite query langugage such as SQL, Google Analytics, Amazon Book Search, Google Image Search etc.

Yes, I was unclear. The reason why lambda expressions are lazy is the LINQ guys wanted lazy evaluation. Querying database is slow and if laziness allows them to avoid it, it's well worth having a slightly higher overhead.
So MS significantly changed semantics of unrelated feature to give it to them.

I usually look at MSDN. If it's not enough, I look decompiled output of corresponding method with online or offline tools.

The problem that I had was that general overviews of various language properties never contain any reference to exceptions, so you have no chance to learn them other then to stomp on a bug where something doesn't work and to see in the docs of the particular feature that it changed some general rule. One concrete example is the already mentioned laziness suddenly appearing in a tiny subset of the language. Another is that equals() compares objects of particular classes not by contents but by references. The objects that I'm aware of (maybe there are others too, I won't know unless I ever get a bug with them) are collections. Great, MS run out of budget or time to implement the thing correctly, so they released it broken. And later, instead of fixing it, added a workaround in the form of SequenceCompare function. Mess, mess, mess.

[osmanturan]

Yes, I was unclear. The reason why lambda expressions are lazy is the LINQ guys wanted lazy evaluation. Querying database is slow and if laziness allows them to avoid it, it's well worth having a slightly higher overhead.

I think, you're confusing lambda and LINQ. Lambda functions are not lazy evaluated. They are simply delegates (or anonymous functions). You can even invoke a lambda function asynchronously. But, these are irrelevant to lazy evaluation. For LINQ case, lazy evaluation is "must-have". Because, you can add queries on queries. So, at data reading, they have to be evaluated to simplify LINQ queries to actual data queries (say SQL). To make it clear, here is "real" product "LINQ to SQL" code from our applications:

private static IQueryable<UdtProject> BuildQuery(ModuleDataContext context,
    int companyID, int engineerID, int cityID, int countyID, string approvalState)
{
    var query = from x in context.UdtProjects select x;

    if (companyID > 0)
        query = from x in query where x.CompanyID == companyID select x;

    if (engineerID > 0)
        query = from x in query where x.EngineerID == engineerID select x;

    if ((cityID > 0) && (countyID < 0))
        query = from x in query where x.County.CityID == cityID select x;

    if (countyID > 0)
        query = from x in query where x.CountyID == countyID select x;

    if (!String.IsNullOrEmpty(approvalState))
    {
        UdtProjectApprovalState state = ObjectParser.ParseEnum<UdtProjectApprovalState>(approvalState);
        query = from x in query where x.ApprovalState == state.ToString() select x;
    }

    return query;
}

This code does not execute any single line of SQL code. It accumulates LINQ queries over and over again by given filtering parameters. If you want to fetch data you can just simply call "query.ToArray()" to compile LINQ query into SQL on demand. As to overhead, it's very little today with service packs. At first times, it was damn slow comparing to precompiled queries.

Here is the code that calls the above code. Note that until "ToArray()", it's still not evaluated.

...
using (ModuleDataContext context = new ModuleDataContext(CmsHelper.ConnectionString))
{
    var query = BuildQuery(context, companyID, engineerID, cityID, countyID, approvalState);

    return (from x in query
            orderby x.CreationTime descending, 
                    x.ReviewTime descending, 
                    x.ApprovalTime descending
            select x).ToArray();
}
...

...One concrete example is the already mentioned laziness suddenly appearing in a tiny subset of the language. Another is that equals() compares objects of particular classes not by contents but by references. The objects that I'm aware of (maybe there are others too, I won't know unless I ever get a bug with them) are collections...

"Equals()" are used for reference equality by default. In intellisense tip, description is clear to me. It compares references not actual data. If you want to compare containing data, there is a IEquatable interface for such usages (you have to implement that interface for your objects). If you want to extend this "comparing containing data" feature to all objects, you can still write a simple extension method which invokes reflection to compare arbitrary classes' containing data.

I think, you make some assumption before using a method and that causes to pull you into trouble. Fastest way could be just read intellisense tip.

[m^2]

I think, you're confusing lambda and LINQ. Lambda functions are not lazy evaluated.

I'm not mixing them up, but it is possible that what I read was incorrect or that I got it wrong. It really enraged me back then. Now I did a search and there are not many results on the topic, which suggests that it's not true.

"Equals()" are used for reference equality by default. In intellisense tip, description is clear to me. It compares references not actual data. If you want to compare containing data, there is a IEquatable interface for such usages (you have to implement that interface for your objects). If you want to extend this "comparing containing data" feature to all objects, you can still write a simple extension method which invokes reflection to compare arbitrary classes' containing data.

I think, you make some assumption before using a method and that causes to pull you into trouble. Fastest way could be just read intellisense tip.

I don't have a C# IDE. Do you mean reading a tip for each and every use of any function on any object that I don't remember is correct?
Thanks, but I prefer languages that define some rules and follow them.

The first search engine result for "c# equals msdn":
https://blogs.msdn.com/themes/blogs/...als&GroupKeys=
It clearly talks up the differences between them and mentions an exception. No, not the one that I meant, Strings.

It's the second time I have such discussion with a C# dev. The first one wasn't bothered either. Guess it's a matter of personality. I have strong bias towards solving problems in elegant ways and elegance doesn't seem to matter for MS at all.

[osmanturan]

I don't have a C# IDE. Do you mean reading a tip for each and every use of any function on any object that I don't remember is correct?

Yes, I agree it's not convenient. The problem lies in design pattern of CLR. Language extensions are rely heavily on interfaces. For example, if you want to enable "LINQ to Object" for a static collection, you have to implement "IEnumerable<T>"; if you want to use "using () {}" block, you have to implement "IDisposable" etc. In that sense, IEqualitable makes sense.

[Piotr Tarsa]

> When it comes to memory allocation then garbage collected implementations win.

Yes, but in C/C++ its a useful option, while in java/C# its unavoidable.

Things like reference counting are slow as hell, so it's a very poor alternative to modern GCs. Is there any C++ implementation with good GC performance?

Unfortunately exceptions need supporting code everywhere.
Also while they may not affect the program's speed directly,
but they do affect program's architecture (handle ptr==0 here,
or handle an exception somewhere higher up).

Without JVM you need support for exceptions in hardware. SIGSEGVs aren't generated by software. And with hardware implementation you need to care about exceptions with eg every instruction that deals with memory. JVM's are smart enough to deduce that most array bounds checks are not needed and removes them. So there's a win for JVM.

Don't forget multiple cores etc.

I haven't.

But hardware multitasking is better, and software simulations
are inefficient.

Hardware solutions costs silicon, increase power usage, manufacturing cost, design cost (software is IMO easier to develop than hardware), etc With some workloads Hyper-Threading even decreases performance and I think there's not even bearably hard (not to mention simple) way to predict that statically.

With dynamic compilation VM can test various optimization techniques and then leave only those most performant. It's equal to profiling the code, but the profiling is always enabled, code adapts to usage schemes all the time. You can't statically optimize code for all usage scenarios.

TLB is not used in "real mode", so that option is actually available.

How many humans use code written for real mode nowadays?

In C, to concatenate strings stored in specific memory locations
using specific layout (asciiz or length-prefixed) you have
to allocate more memory, and then store the strings there.

JVM does almost exactly the same thing. The only overhead that JVM has is the vtable traversing. But that's what devirtualization is for.

But then you'd eventually hit some implicit limits
(like max length of a string is 2G; or garbage collector
suddenly freezing up your app after a few millions of
string concatenations)

That's tied to particular VM specifications or implementation. I'm talking about VMs in general, not only about JVMs. If you want JVM with low pauses then choose: http://www.azulsystems.com/


Java has dynamic devirtualization, deoptimization (if the workload is different from those that the code was optimized to), escape analysis, lock ellision, bounds checking elimination and tons of other optimization techniques.
Look at that code: http://pastebin.com/KBihXKR2
The output on my system is:
577
-699150247503735895
615
-699150247503735895
572
-699150247503735895
645
-699150247503735895
So basically all four methods of doing computations yields the same performance on my system.



Let assume that Java code runs twice slower than C/C++ code (using good implementations in both cases) and Java code requires twice as many RAM (managed code has a lot of overhead over unmanaged code). That are very pessimistic assumptions and basically holds only for very optimized code. Cost of engineering software is often much higher than buying additional hardware. With productive languages you can optimize more quickly and by optimization I do not mean lowering the constant in Big-Oh notation but lowering the asymptotical complexity. Managed code is finally much easier to debug, even stacktraces are much more useful info for developer than messages like "access violation at 0xabcdef. memory can't be read".

Nowadays, most of casual workloads like surfing Internet, editing documents, playing simple games, etc aren't very demanding. People happily run such workloads on old machines and developers are even building increasingly complex application in hard to optimize languages like JavaScript. JavaScript is usually a few times slower than Java (Google V8 vs Oracle JDK 7: http://shootout.alioth.debian.org/u64/javascript.php). Even the upcoming Metro UI for Windows 8 will use JavaScript (or ECMAScript, that's basically the same thing for me). I've also read that GNOME 3 has some JavaScript bits inside. I see also a lot of software written in Python in Ubuntu repositiories.



Summing up, I see bright future for managed platforms. That said, I don't particularly mean any current managed platform. Maybe Java and .NET will end up being next COBOL (a language in which a lot of software is written, but almost no one writes new software because of much more convenient languages available)? Managed platfors are increasingly popular, while unmanaged platforms sees popularity reduction.



PS:
As to WinXP popularity: MS ends support for WinXP in 2014. I expect major software companies to also stop supporting WinXP around the same time. That should force those reluctant people to switch to supported systems.

[Shelwien]

http://nishi.dreamhosters.com/u/win8.txt

[Black_Fox]

and they will also need to
develop a Metro version of their applications for Intel processors
(if they choose to do this), and a Metro version of their
applications for ARM processors (if they choose to do this)

This is wrong. Metro uses HTML5, CSS and JS. Usage of WinRT breaks portability with non-Windows, but one app should work on all Windows8 installations.

Other than that, yeah, that article sums it up prettily. I am repulsed by Metro as a desktop kbd&mouse user. Can't talk for tablet experience as I don't own any

[osmanturan]

This is wrong. Metro uses HTML5, CSS and JS.

This is also wrong. Metro apps (immersive apps) do not bound to "only" HTML5. You can use .NET as well. Immersive apps actually run in a sandbox and all I/O is under control. Immersive apps is not meant to replace desktop apps. They are planned for Microsoft App Store as a response to Apple's App Store. In Microsoft App Store, all immersive application will be statically analyzed to ensure there is no I/O related behaviour (including reflection based accesses). In short "Immersive apps" != "Desktop apps". They have different purposes.

Another off topic thing that, with Windows 8, native C++ applications can use WPF which has great flexibility and speed over classic Win32 UI. Currently, it can be used by only .NET and Silverlight applications.

[Piotr Tarsa]

I think that touch interface has no chance on desktops. AFAIR I've read that Apple tested touch-screen desktop monitors and they were painful to operate - try holding hands in air for a long time. On desktops we have keyboards with lots of keys that can be bound to particular functions, we have mouses with multiple scrolls and buttons, for drawing we have Wacom tablets, etc Touch interface on desktops isn't going to work IMO. So most probably desktops and tablets will continue to be completely different markets/ approaches if we are talking about interfaces. But the backends could be shared.

Trends are towards web based applications. Maybe soon even WebGL will take on "immersive" applications. HTML5 (with all the additional technologies) is very convenient because we don't need to worry about signing applications, recompiling and packaging for different operating systems, we have single stable API (once HTML5 is finalized of course), etc There is even a widget format for HTML applications.