Board index » kylix » Re: porting a D7 app to Linix - Kylix

Re: porting a D7 app to Linix - Kylix


2006-04-24 06:29:53 PM
kylix2
Not that i particularelly enjoy .net but you are way off with these numbers
(2-10 times slower).
Few months back i've tested the direct mysql 32 version versus and the .net
version. Lots of arrays, buffers sockets etc and to my surprize (unexpected)
the .net version has been faster than the native version (about 70%
runtime).
While this is clearly a subjective point of view .. there are other articles
on the internet which show the same point: bad code is bad code in any
environment :D
Kind regards,
Cristian Nicola
"Marco van de Voort" < XXXX@XXXXX.COM >wrote in message
Quote
On 2006-04-18, Michael Schnell < XXXX@XXXXX.COM >
wrote:
Rule of thumb is that managed code is 2-10 times slower on average than
native
code.
 
 

Re:Re: porting a D7 app to Linix - Kylix

On 2006-04-24, Cristian Nicola < XXXX@XXXXX.COM >wrote:
Quote
Not that i particularelly enjoy .net but you are way off with these numbers
(2-10 times slower).
Few months back i've tested the direct mysql 32 version versus and the .net
version. Lots of arrays, buffers sockets etc and to my surprize (unexpected)
the .net version has been faster than the native version (about 70%
runtime).
I don't fully understand. Are you comparing code you wrote in both
situations or are you benchmarking two components, one of which is a .NET
edition?
...
A co-worker did the same with an in-memory db in C#. I checked the code, and they
were consistent with earlier real-world Java experiences, to above values.
I know some cases where it turned out Java was faster, but they seemed to
revolve around situation where the application was bound by copying blocks
in memory, which was really optimized by the JIT code that chose an
optimized implementation.
Quote
While this is clearly a subjective point of view .. there are other articles
on the internet which show the same point: bad code is bad code in any
environment :D
It's very hard to find independant analysis of this subject. Most of the
articles are from sites that focus on pushing either .NET or Java. One never
knows if the comparison is equal.
 

Re:Re: porting a D7 app to Linix - Kylix

Comments inline:
"Marco van de Voort" < XXXX@XXXXX.COM >wrote in message
Quote
On 2006-04-24, Cristian Nicola < XXXX@XXXXX.COM >wrote:
I don't fully understand. Are you comparing code you wrote in both
situations or are you benchmarking two components, one of which is a .NET
edition?
Direct mysql is a collection of classes that allow you to talk to mysql
server. With other words an implementation of the wire protocol of mysql.
The version i'm talking about doesnt use any dynamic memory as in pointers
but dynamic arrays. This is the only code i've ever ported to the .net just
as a quick test (i've only actually had to write the sockets
create/connect/read/write/close parts).
Both versions are delphi code, but used in different projects.
Running various sql statements, either with or without results, with large
resultsets and so on.. over all the .net execution takes about 70% of the
time in win32.
It is hardly a scientific experiment (especially since there is some network
involved) but my biggest surprize has been that the .net code has been
faster in any tests. If asked i would not even blinked before betting on the
native code being faster :D
Also this little experiment did NOT accounted the load time of the exe...
which for the native code is smaller as one would expect.
My very personal perception is that classes, dynamic arrays, strings etc are
actually faster than the classic delphi equivalent.
Also i was reading the other day an article from one of the microsoft
"teamb" guys and he tested some math operations - the .net code has been
faster than the native code in his test also - he provided the source code
if you'd like to test it yourself.
Worth adding that i do NOT use .net .. just been looking for a bit :D
Quote

It's very hard to find independant analysis of this subject. Most of the
articles are from sites that focus on pushing either .NET or Java. One
never
knows if the comparison is equal.
Have a look at this article:
www.grimes.demon.co.uk/dotnet/man_unman.htm
Kind regards,
Cristian Nicola
 

{smallsort}

Re:Re: porting a D7 app to Linix - Kylix

On 2006-04-24, Cristian Nicola < XXXX@XXXXX.COM >wrote:
Quote
Comments inline:
In there another way? :-)
Quote
"Marco van de Voort" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...
>On 2006-04-24, Cristian Nicola < XXXX@XXXXX.COM >wrote:
>I don't fully understand. Are you comparing code you wrote in both
>situations or are you benchmarking two components, one of which is a .NET
>edition?
Direct mysql is a collection of classes that allow you to talk to mysql
server. With other words an implementation of the wire protocol of mysql.
The version i'm talking about doesnt use any dynamic memory as in pointers
but dynamic arrays. This is the only code i've ever ported to the .net just
as a quick test (i've only actually had to write the sockets
create/connect/read/write/close parts).
Both versions are delphi code, but used in different projects.
Running various sql statements, either with or without results, with large
resultsets and so on.. over all the .net execution takes about 70% of the
time in win32.
And the used mem is the same? Since this is of course very dependant on
caching:-)
Quote
My very personal perception is that classes, dynamic arrays, strings etc are
actually faster than the classic delphi equivalent.
Also i was reading the other day an article from one of the microsoft
"teamb" guys and he tested some math operations - the .net code has been
faster than the native code in his test also - he provided the source code
if you'd like to test it yourself.
I can be brief about this:
Category I:
I've seen lots of benchmark like heavily calculating code that was faster by
the fanboys of both HotSpot and .NET. All examples of tight loops of
math or image processing code that benefits strongly of the profiled
compilation (btw, it's not that profile driven optimization is not possible with
native code, but it is a lot rarer, and worse, not standard, and delphi
doesn't do it).
However I don't care much about benchmarks, they seem to stress stuff that
isn't a bottleneck in most applications. Also there is a risc that they are
specially crafted. I can imagine this category making a difference for e.g. photoshop
filters, but since there afaik is no Java/.NET photoshop that is only a
guess.
Category II:
I've seen one (and maybe one more that was likely so, but not entirely
verified) of real apps that were faster than the native equivalent, the
memory copying seemed to be the bottleneck. An advantage that went away if
the move() operation was also CPU optimized, but that requires separate
deployment for the optimized version, that is only worthwhile in certain
cases, so I still write this up as a win for .NET.
If sb has verifyable examples of this category (e.g. in the Open Source sector, or
with opened up apps/components), I'd be very interested. The verifyable
example was my employers, so effectively I have none.
For the rest, a two handfull apps, I saw the said factor 2-10 for managed
code. (more Java hotspot than .NET, .NET slightly better, but not
spectacular on avg)
Quote
>knows if the comparison is equal.

Have a look at this article:

www.grimes.demon.co.uk/dotnet/man_unman.htm
I know it. Typically Category I.
Also note the careful wording and the only microscopic better results.
Managed _can_ be faster, but he doesn't say how many experiments he had to
perform to find this example.
 

Re:Re: porting a D7 app to Linix - Kylix

Am 13.04.2006 18:26 schrieb Felipe Monteiro de Carvalho:
Quote
Matthias Frey wrote:
>Hello,
>since more than ten years i developed a large application
>vor single enduser. First mit mit Turbo-Pascal, now with
>Delphi 7, Delphi 2006 is still in a box.

Is you application based on VCL or CLX?
VCL - i thought, it's clear
Quote
If itīs based on VCL, I sugest that you try Lazarus.
I will do.
Quote
It works great on all Linux distributions (acctually on all UNIXes from
Solaris to FreeBSD, Linux and Mac OS X)
Great with my application too?
Quote
A screenshot of the IDE running a popular software created with Lazarus:

sourceforge.net/project/screenshots.php
I need more like this:
matthias-frey.de/pub/imgcms/feat/Scp_Nebenfenster.png
Quote
>Is .NET and Mono a good idea?

Itīs a really good idea if you wish your software to be 15 times slower,
to use 10 times more memory and to require all users to install heavy
run-time environments.
That doesn't matter to me. I don't need the best solution, i need *one*.
Quote
Felipe
Thx
Matthias
 

Re:Re: porting a D7 app to Linix - Kylix

On Tue, 02 May 2006 14:25:41 +0200
Matthias Frey < XXXX@XXXXX.COM >wrote:
Quote
I need more like this:
matthias-frey.de/pub/imgcms/feat/Scp_Nebenfenster.png
Looking at this form I foresee following issues:
- Toolbars are not as flexible/functional as in delphi, so the main menu
will need to be 'old style' ie. separate. Lazarus itself uses a panel with
speedbuttons as a kind of toolbar (non-movable, it is).
- PageControl/TreeView work quite well.
- MDI is not supported, forms with parent another form does not function
well. A PageControl (or other MDI-alike functionaility) is recommended here.
- TRichEdit is not implemented at all, there is turbopower's ipro html
component that works ok.
I hope this gives you an idea on the amount of work required.
Micha
 

Re:Re: porting a D7 app to Linix - Kylix

Cristian Nicola wrote:
Quote
Not that i particularelly enjoy .net but you are way off with these numbers
(2-10 times slower).
Acctually here is the Debian Benchmark comparing Free Pascal to C#:
shootout.alioth.debian.org/gp4/benchmark.php
The real result should be 15 to 20 times slower.
Also c# uses about 15 more memory for the same problem.
 

Re:Re: porting a D7 app to Linix - Kylix

If you have any problems using Lazarus fell free to drop us a note at
the Lazarus mailing list and we will do what is possible to help.
For the MDI part I recommend using MultiDoc component for Lazarus. Isn't
perfect, but works very well:
wiki.lazarus.freepascal.org/index.php/MultiDoc
thanks,
Felipe
 

Re:Re: porting a D7 app to Linix - Kylix

Quote

Acctually here is the Debian Benchmark comparing Free Pascal to C#:

shootout.alioth.debian.org/gp4/benchmark.php

"Mandelbrot" is two times faster in C# ?!?!?!?!?
So it seems to depend greatly on the task to be done.
-Michael
 

Re:Re: porting a D7 app to Linix - Kylix

On 2006-05-07, Michael Schnell < XXXX@XXXXX.COM >wrote:
Quote
>
>Acctually here is the Debian Benchmark comparing Free Pascal to C#:
>
>shootout.alioth.debian.org/gp4/benchmark.php
>

"Mandelbrot" is two times faster in C# ?!?!?!?!?

So it seems to depend greatly on the task to be done.
Possible yes, while there are some mitigating facts (optimization level, compiler
version etc), I'd expect such tight benchmarks to be stuff where FPC is less
ok.
Mandelbrote IIRC requires a compiler can that optimizes a basic
auto-recursion with a relative small function body heavily. This is a boon
for VMs that can optimize at runtime. It is a pity that it pretty much only
exists in certain mathematical problems tho.
Also note that Mono eats _40_ times the memory that FPC uses. (I say mono(
or mono/C# if there are several) and not "just" C#, it is always
implementations that you test, not languages)
This illustrates that comparing on benchmarks is _very_ dangerous, since
heavy optimizing compiler often excel in it, while they can't reach such
speedups in real applications, except for some specialistic ones. (like
numeric math, a field which most compilers optimize for)
FPC is slowly creeping up, also in the benchmarks, but the benchmark
business is a hobby for us. Real apps (both speedwise and functionwise) is
the real target, and while keeping an eye on speed (runtime and startup) and
memory consumption is very important, going for the last cycle or byte in
each situation doesn't pay off.
FPC has a bit odd optimization target. The most important reference application
is the compiler itself. In practice this works out quite fine since the
compiler is a "real" app, not just a 100 line benchmark.
 

Re:Re: porting a D7 app to Linix - Kylix

Agreed !
-Michael
 

Re:Re: porting a D7 app to Linix - Kylix

Am 06.05.2006 18:05 schrieb Micha Nelissen:
Quote
On Tue, 02 May 2006 14:25:41 +0200
Matthias Frey < XXXX@XXXXX.COM >wrote:

>I need more like this:
>matthias-frey.de/pub/imgcms/feat/Scp_Nebenfenster.png

Looking at this form I foresee following issues:

- Toolbars are not as flexible/functional as in delphi, so the main menu
will need to be 'old style' ie. separate. Lazarus itself uses a panel with
speedbuttons as a kind of toolbar (non-movable, it is).
Bad, but not to bad.
Quote
- PageControl/TreeView work quite well.
Fine
Quote
- MDI is not supported, forms with parent another form does not function
well. A PageControl (or other MDI-alike functionaility) is recommended here.
That's hard. A PageControl ist not possible. The user have to
compare several window.
Quote
- TRichEdit is not implemented at all, there is turbopower's ipro html
component that works ok.
I don't need it. What you see is an own component.
For html i use components from www.pbear.com
Quote
I hope this gives you an idea on the amount of work required.
An idea? No. But i see more clearly what to do - and what i have to go.
Quote
Micha
Matthias
 

Re:Re: porting a D7 app to Linix - Kylix

Not that i want to be the nay-saying - please note that the CPU still costs
much more than memory...
Cristian Nicola
"Marco van de Voort" < XXXX@XXXXX.COM >wrote in message
Quote
On 2006-05-07, Michael Schnell < XXXX@XXXXX.COM >
wrote:
>>
>
>"Mandelbrot" is two times faster in C# ?!?!?!?!?
Also note that Mono eats _40_ times the memory that FPC uses. (I say mono(
or mono/C# if there are several) and not "just" C#, it is always
implementations that you test, not languages)
 

Re:Re: porting a D7 app to Linix - Kylix

On 2006-05-08, Cristian Nicola < XXXX@XXXXX.COM >wrote:
Quote
Not that i want to be the nay-saying - please note that the CPU still costs
much more than memory...
A medium high CPU (say a 3800 X2) or a highend amount of memory (say 4GB, in 1 GB
Dimms since most workstations have 4 slots also costs the same.
And we are not talking about twice the mem, but _40_ times the mem. If I
standard have 1GB and say that 768 MB of that is application mem, I would
need 40 times 3/4 MB=30 GB memory to have the same effect.
 

Re:Re: porting a D7 app to Linix - Kylix

It is not linear and it is just comparing apples with oranges
a hello world application may be 40 times the memory footprint but as you
add complexity the 40 times does not keep up.
"Marco van de Voort" < XXXX@XXXXX.COM >wrote in message
Quote
A medium high CPU (say a 3800 X2) or a highend amount of memory (say 4GB,
in 1 GB
Dimms since most workstations have 4 slots also costs the same.

And we are not talking about twice the mem, but _40_ times the mem. If I
standard have 1GB and say that 768 MB of that is application mem, I would
need 40 times 3/4 MB=30 GB memory to have the same effect.