Steve,
Thank you for posting. It will come helpful in the future
when
somebody will ask to go .NET way :-)
Some background for those
who may not be aware about C# story: C# was
actually Microsoft response to
Sun's Java.
Microsoft had some conflict with Sun about MS Visual J++ (which
was
MS-Java). So Microsoft thought that they will come with something
that looks like Java, works like Java (is platform independent) but
it
is Microsoft's own and they don't need to worry about Sun's
intellectual
property. So they came up with C# that "borrows" most of
ideas from Java
including the fact that it is translatted to similar
platform-independent "byte-code" (CLI in MS-speak) that is later
interpreted at run-time.
As execution of such program involves
interpretation in run-time it
just runs slower. Yes both Java and .NET now
have on-the-fly byte
code compilers that are supposed to deliver native
speed but practice
shows that the CLI/bytecode is slower than real native
code.
This comes as no surprise to me. Especially considering the
fact
that C/C++ allows going down to assembly level (working with direct
machine code). I did machine-code level optimizations for basic
arithmetic operations in AFL and this resulted in significant speedup
in AFL execution. This would not be possible with Java.
In C# it is
possible to mix parts in "unmanaged" code for speed - and
this "unmanaged"
code is exactly what good old C/C++ produces
but the practice shows that C#
makes programmers lazy and they rarely
bother about coding parts in tight
unmanaged code because there is
always pressure to deliver program "for
yesterday" and "we will
optimize it later" but the "later" never comes
because there is next
version that must be shipped in the hurry.
I have
seen that in many software companies and there is never time
to perfect
little parts of the code.
Fortunatelly with AmiBroker the story is quite
different.
I have no "managing board" telling me what I should do or that I
should hurry up. I can spend 2 weeks on 20 lines of code if I want to
and nobody is able to say "stop wasting time on this little
optimization because we passed the deadline".
I can say "no" to .NET
even if everybody is evangelizing how "modern
and fast to develop in" it
is.
Yes C/C++ is slow to write in, but it does not make you lazy and
it
forces you to think. The only way to get quick effects in C/C++ is to
think alot prior to start coding. If you have well-thought concept,
you
can write in C/C++ pretty fast.
Best regards,
Tomasz
Janeczko
amibroker.com
--- In amibroker@xxxxxxxxxps.com,
"scourt2000" <stevehite@x..> wrote:
>
>
> I've
been playing around with some "other charting packages" out
> there and
there's one theme that runs through all of them: if the
> charting
package is based on .Net, it's going to be a performance
> dog compared
to a C++ native code-programmed app.
>
> THANK YOU Tomasz for not
getting on the .Net bandwagon. For real-
> time stock market and futures
charting, it may be easier to program
> in C# than C++, but your
end-users will suffer the consquences of
> that decision.
>
> It won't matter when computers are twice as fast as they are now,
> but now, there's a noticeable difference in performance and
>
responsiveness. I'm not even talking about being clever about
>
backtesting speed-ups and the like. I'm talking about basic data
>
retrieval, plotting and user manipulation of the charts.
>
>
Anyway, had to get that out of my system. Kudos to you Tomasz!
>
>
Steve
>