Session material: Differences between VO and X#

[robert]

Wolfgang,
and the good thing is, we all know

Winter is coming...

Robert

[Chris]

I concur, that's very nice Wolfgang!

Just one further minor correction, there's no problem actually representing 123456789 or any other integer number (or decimal with zero decimal part) with the float/single/real datatypes,

The problem appears when you need to store the decimal part of a number in such a datatype, for example 0.123456789 or 12345.6789 or 12345678.9 indeed cannot be represented correctly in numeric data types other than System.Decimal.

[wriedmann]

Hi Chris,

thank you very much for your correction! I have added them to the document and uploaded the changed version-

If someone thinks I have not covered something please let me know!

Wolfgang

[ic2]

Hello Wolfgang,

Amazing how much time you spend in producing useful X# info. I forwarded the document + link (as it will be updated from there I suppose) to my employees.

Thanks!

What I found a bit alarming is that you conclude that X# is actually slower. I am aware of the "start gap" present in all .Net programs but I thought that most code would run faster.



Dick

[wriedmann]

Hi Dick,

What I found a bit alarming is that you conclude that X# is actually slower. I am aware of the "start gap" present in all .Net programs but I thought that most code would run faster.

Where do you found this information? In the page where the decimal datatype is discussed?

Microsoft itself states that decimal is slow, but I have newer compared float with decimal myself.

When it comes to large arrays, X# is ways faster than VO.

Wolfgang

[ic2]

Hi Dick,

Where do you found this information? In the page where the decimal datatype is discussed?
When it comes to large arrays, X# is ways faster than VO.

On page 14. There it says:

"X# has been developed with performance in mind. But code executed in the .NET runtime
is slower than native code like VO. "

So that seems the opposite of what you write above?

Dick

[wriedmann]

Hi Dick,

VO is native machine code, so in pure processing it should be faster than code executed in the under the .NET runtime.
But the better memory managment and optimized datatypes should make this gap smaller or even make a X# application faster.
From tests from other people I know that Vulcan was effectively slower than VO.

But I will make some tests to see a difference, and let you know.

Wolfgang

[FFF]

I remember Sabo showing that Vo was only 10% slower than C. That's hard to beat for a way "upstream" language based on .net framework
But again, i doubt in reality every day apps the pure crunching power to be of any notifiable impact.

Karl

[wriedmann]

I have done now a small test, using this code:

Code: Select all

nReal1 := 0
nReal2 := 0
for nI := 1 upto nLen
  nReal2 := nReal1 + nReal2
next

for 1.000.000 of iterations.

These are the values for X# with the Vulcan runtime:
Duration for Int:00:00:00.0059964
Duration for Real8:00:00:00.0029983
Duration for Float:00:00:00.0089958
Duration for Decimal:00:00:00.0199881

These are the values for X# with the X# runtime:
Duration for Int:00:00:00.0069954
Duration for Real8:00:00:00.0029983
Duration for Float:00:00:00.0079989
Duration for Decimal:00:00:00.0199892

and these for VO 2.8 (no decimal available):
Duration for Int: 0,000100
Duration for Real8: 0,016100
Duration for Float: 0,062100

So the int is ways faster in VO, but Real8 and float are faster in .NET.
The float works better in the X# runtime, the int better in the Vulcan runtime.

Wolfgang

[lumberjack]

Hi Dick,

On page 14. There it says:
"X# has been developed with performance in mind. But code executed in the .NET runtime
is slower than native code like VO. "
So that seems the opposite of what you write above?

You should read it carefully. All .net applications are slower than native applications, due to the JIT compiler.

If you create a .BAT file that executes a .net application say 1000 time, and compare it to executing the same application written in native mode, even a small "Hello World" application:

Code: Select all

FUNCTION Start() AS VOID
  Console.WriteLine("Hello World")
RETURN

FOR i := 1 TO 1000
  RUN HelloWorld.NET.exe
NEXT

FOR i := 1 TO 1000
  RUN Application.NATIVE.exe
NEXT

In the above example, the native HelloWorld will be faster than the .net version due to the penalty of the JIT compiler. It needs to compile 1000 times.

However in the below example:

Code: Select all

FUNCTION Start() AS VOID
  FOR i := 1 TO 1000
    Console.WriteLine("Hello World")
  NEXT
RETURN
RUN HelloWorld.NET.exe
RUN HelloWorld.NATIVE.exe

In this scenario, it should be a close call internally, since both are now actually "native". My bet is though that the .net version will outperform the native application due to better resource management/optimization.
Hope this clarify the "slower" .net statement.