keyongtech


  keyongtech > cobol > 10/2003

 #1  
09-26-03, 08:42 PM
Grinder
Steve Thompson mention the "Indian Problem" -- How much would
12.00 be today if it was put in the bank in 1626, when
Manhattan was purchased?

Benchmarking this simple logic likely proves nothing, but it is
yield some interesting results:

mpb Visual COBOL 3.6.0.8
Test Count: 100000
Init -------------------------
Year: 1626
Principle: 12.0000
Rate: 0.0400
Results ----------------------
Principle: 31674824.8227
Elapsed: 52850

Borland Delphi 5.0
Test Count: 100000
Init -------------------------
Year: 1626
Principle: 12.0000
Rate: 0.0400
Results ----------------------
Principle: 31677245.6417
Elapsed: 1783

Microsoft Visual Basic 6.0
Test Count: 100000
Init -------------------------
Year: 1626
Principle: 12.0000
Rate: 0.0400
Results ----------------------
Principle: 31677245.6417
Elapsed: 3505

I'll post the code if anyone is interested.
 #2  
09-26-03, 09:46 PM
Grinder
Here's another one:

Microsoft C#.net 1.0
Test Count: 100000
Init -------------------------
Year: 1626
Principle: 12.0000
Rate: 0.0400
Results ----------------------
Principle: 31677446.1774
Year: 13830

The difference in resultant principle is pretty interesting.

31674824.8227 (mbp COBOL)
31677245.6417 (VB)
31677245.6417 (Delphi)
31677446.1774 (C#)

A tentative explanation:

mbp COBOL -- truncates digits beyond those defined in the PIC.
(Is that right?)

VB, Delphi -- rounds digits beyond the 4th digit after the
decimal (Currency types are 64-bit integers with a presumed
numeric scale of 4.)

C#.net -- I used the "decimal" type which a 128-bit integer
scale by 10, but it keeps more digits past the decimal point
than 1. It has a precision of about 28, but it's unclear to me
how it determines numeric scale. It coerces to and from
integer types implicitly, so it's apparently not a floating
point type.
 #3  
09-27-03, 03:39 AM
Grinder
mbp Visual COBOL 3.6.0.8
Test Count: 100000
Init -------------------------
Year: 1626
Principle: 12.0000
Rate: 0.0400
Results ----------------------
Principle: 31674824.8227
Elapsed: 36610
Time Zero: 200309262133579500000
Time Final: 200309262134345600000

Microsoft C#.net 1.0
Test Count: 100000
Init -------------------------
Year: 1626
Principle: 12.0000
Rate: 0.0400
Results ----------------------
Principle: 31677446.1774
Year: 13629

Microsoft Visual Basic 6.0
Test Count: 100000
Init -------------------------
Year: 1626
Principle: 12.0000
Rate: 0.0400
Results ----------------------
Principle: 31677245.6417
Elapsed: 3508

Borland Delphi 5.0
Test Count: 100000
Init -------------------------
Year: 1626
Principle: 12.0000
Rate: 0.0400
Results ----------------------
Principle: 31677245.6417
Elapsed: 1772

____

I guess I'll start going through whatever orphaned
compilers/interpreters are lying around...
 #4  
09-28-03, 05:17 AM
Howard Hess
On Fri, 26 Sep 2003 15:46:06 -0500, "Grinder"
<grinder> wrote:

[..]
>numeric scale of 4.)
>
>C#.net -- I used the "decimal" type which a 128-bit integer
>scale by 10, but it keeps more digits past the decimal point
>than 1. It has a precision of about 28, but it's unclear to me
>how it determines numeric scale. It coerces to and from
>integer types implicitly, so it's apparently not a floating
>point type.
>FWIW, here's a REXX program and its result to a ridiculous number of

decimal places.

/* REXX */
Numeric digits 1000
Amount = 12
Rate = 1.04
do i = 1627 to 2003
Amount = Amount * Rate
end
say Amount
exit


31677446.17743422889228418776648561466364843844648 47468309094416987301114925357384612428149183625963 29347920155063428447224975073580841262865070547515 86902038144624046835577978056939872068237751168981 83839905392551153457097454200720367653556557064869 64232697965627051165009945014786784184741528062093 35931328868273376368853515535467412697780999704765 29040421927405325721582091424222372237861744291729 06921222668152091280844347034797366456404485116993 53560983227208145798885920474102102026626341489481 18449792137270703240033533478265344867300315542846 32362136516555373660332858366759246811723867961874 51237419984099055736210287022534537679157839811672 54513088709436544314033090449023037421491594431500 14623375146558783140858748164066018275874188216682 1096372830208
 #5  
09-28-03, 10:02 AM
Grinder
> FWIW, here's a REXX program and its result to a ridiculous
number of
> decimal places.
>
> /* REXX */
> Numeric digits 1000
> Amount = 12
> Rate = 1.04
> do i = 1627 to 2003
> Amount = Amount * Rate
> end
> say Amount
> exit
>>

31677446.17743422889228418776648561466364843844648 4746830909441
69873011149253573846124281491836259632934792015506 3428447224975
07358084126286507054751586902038144624046835577978 0569398720682
37751168981838399053925511534570974542007203676535 5655706486964
23269796562705116500994501478678418474152806209335 9313288682733
76368853515535467412697780999704765290404219274053 2572158209142
42223722378617442917290692122266815209128084434703 4797366456404
48511699353560983227208145798885920474102102026626 3414894811844
97921372707032400335334782653448673003155428463236 2136516555373
66033285836675924681172386796187451237419984099055 7362102870225
34537679157839811672545130887094365443140330904490 2303742149159
44315001462337514655878314085874816406601827587418 8216682109637
2830208

Thanks, I'll take the opportunity to install a REXX
interpreter/compiler? and get a timing to compare with the
others.
 #6  
09-28-03, 11:40 AM
Alfred Cleve
Hello Grinder,

> The difference in resultant principle is pretty interesting.
>
> 31674824.8227 (mbp COBOL)
> 31677245.6417 (VB)
> 31677245.6417 (Delphi)
> 31677446.1774 (C#)


there are nice differents... i coded the problem with tiny-cobol and my
result is 31677446,1747764224

The working-variable of Amount was pic 9(8)v9(10).

Have fun !
Alfred
 #7  
09-28-03, 09:46 PM
Grinder
"Alfred Cleve" <alfred.cleve> wrote in message
news:g051
> Hello Grinder,
>
> > The difference in resultant principle is pretty

interesting.
> >
> > 31674824.8227 (mbp COBOL)
> > 31677245.6417 (VB)
> > 31677245.6417 (Delphi)
> > 31677446.1774 (C#)

>
> there are nice differents... i coded the problem with

tiny-cobol and my
> result is 31677446,1747764224
>
> The working-variable of Amount was pic 9(8)v9(10).


If you have it -- Can I have a Win32 executable to get a
comparative time test?
 #8  
09-28-03, 10:26 PM
Alfred Cleve
Hi,

> If you have it -- Can I have a Win32 executable to get a
> comparative time test?


i will ask in the mailing-list of tinycobol, if anybody can build a
win32-executable for you. My system is Linux... :-)

have fun !
Alfred
 #9  
09-28-03, 11:26 PM
Grinder
I added to you code in an attempt to match the other
implementation -- it's attached at the end. I hope I haven't
introduced any idiocy in the process.

Here's some output:

Regina REXX 3.2
Test Count: 100000
Init -------------------------
Year: 1626
Principle: 12.0000
Rate: 0.0400
Results ----------------------
Principle: 31677446.1785
Elapsed (ms): 75000 +/- 1000

From what I've learned of REXX in the last 10 seconds, it
appears to be doing string-based long arithmetic. This is
reasonable given its goals, but that and probably the
interpretation, adds a lot to the elapsed time. In particular,
using "12.00" and "0.04" for principle and rate respectively,
takes off about 10 seconds.

I see there are ways to store numerics as binaries, so I'll
investigate that. Also, there's probably some way to compile
REXX.

_____________

/* REXX */
Numeric digits 12

TestCount = 100000
InitPrinciple = 12.0000
InitYear = 1626
Rate = 0.0400

Multiplier = 1 + Rate
ThisYear = 2003

say
say "Regina REXX 3.2"
say " Test Count: " TestCount
say "Init -------------------------"
say " Year: " InitYear
say " Principle: " InitPrinciple
say " Rate: " Rate

/* start the clock */
/* Any ideas on how to get fractional seconds? */
Elapsed = DATE("T")

do Test = 1 to TestCount
Principle = InitPrinciple
do Year = InitYear to ThisYear - 1
Principle = Principle * Multiplier
end
end

/* stop the clock */
/* Any ideas on how to get fractional seconds? */
Elapsed = 1000 * (DATE("T") - Elapsed)

say "Results ----------------------"
say " Principle: " Principle
say " Elapsed (ms): " Elapsed "+/- 1000"

exit
 #10  
09-28-03, 11:27 PM
Grinder
"Alfred Cleve" <alfred.cleve> wrote in message
news:f071
> Hi,
>
> > If you have it -- Can I have a Win32 executable to get a
> > comparative time test?

>
> i will ask in the mailing-list of tinycobol, if anybody can

build a
> win32-executable for you. My system is Linux... :-)
>
> have fun !
> Alfred


Thanks and I am.
 #11  
09-28-03, 11:34 PM
Grinder
Summarized:

Environment Principle Elapsed
Regina REXX 3.2 31677446.1785 75000
mbp Visual COBOL 3.6.0.8 31674824.8227 36520
Microsoft C#.net 1.0 31677446.1774 13589
Microsoft Visual Basic 6.0 31677245.6417 3504
Borland Delphi 5.0 31677245.6417 1773

Run report:

Interpreted ==================

Regina REXX 3.2
Test Count: 100000
Init -------------------------
Year: 1626
Principle: 12.0000
Rate: 0.0400
Results ----------------------
Principle: 31677446.1785
Elapsed (ms): 75000 +/- 1000

Compiled =====================

mbp Visual COBOL 3.6.0.8
Test Count: 100000
Init -------------------------
Year: 1626
Principle: 12.0000
Rate: 0.0400
Results ----------------------
Principle: 31674824.8227
Elapsed (ms): 36520

Microsoft C#.net 1.0
Test Count: 100000
Init -------------------------
Year: 1626
Principle: 12.0000
Rate: 0.0400
Results ----------------------
Principle: 31677446.1774
Elapsed (ms): 13589

Microsoft Visual Basic 6.0
Test Count: 100000
Init -------------------------
Year: 1626
Principle: 12.0000
Rate: 0.0400
Results ----------------------
Principle: 31677245.6417
Elapsed (ms): 3504

Borland Delphi 5.0
Test Count: 100000
Init -------------------------
Year: 1626
Principle: 12.0000
Rate: 0.0400
Results ----------------------
Principle: 31677245.6417
Elapsed (ms): 1773
 #12  
09-28-03, 11:56 PM
Donald Tees
"Grinder" <grinder> wrote in message
news:13mr
>
> "Alfred Cleve" <alfred.cleve> wrote in message
> news:g051
> interesting.
> tiny-cobol and my
>
> If you have it -- Can I have a Win32 executable to get a
> comparative time test?
>

It would be interesting to see if how a cobol program that gave the correct
answer using bussiness rules, and how fast the other languages gave the
correct answer each benchmarked. To find out, just change your picture
clause to 9(8)v9(2) rounded. That will give the correct answer. Then adjust
the other routines to fit.

To check the answers and debug, just print a balance sheet for each year.
Three or four columns will do. It is only going to be a dozen pages long,
and you can compare the entire thing in each of the languages as a test.

Progressive errors should be very easy to spot.

Donald
 #13  
09-29-03, 02:20 AM
Grinder
> It would be interesting to see if how a cobol program that
gave the correct
> answer using bussiness rules, and how fast the other

languages gave the
> correct answer each benchmarked. To find out, just change

your picture
> clause to 9(8)v9(2) rounded. That will give the correct

answer. Then adjust
> the other routines to fit.


The ROUNDED clause go on to the MULTIPLY statement?
 #14  
09-29-03, 03:34 AM
Grinder
I've taken Donald Tees' advice, and now the resultant principle
values are in agreement. This generally increased computation
time, but that has been offset by cutting the size of the local
variables -- slightly for REXX and COBOL, but significantly for
the others.

REXX gets pounded by the 40 million rounding operations it must
now make, but that may be because I don't know the optimal
path -- are there any rexxperts who can assist? (That code
posted as a reply to this note.)

Summary:

Compiler/Interpreter Principle Elapsed
-------------------------- ----------- -------
Regina REXX 3.2 31658845.52 164000
mbp Visual COBOL 3.6.0.8 31658845.52 46380
Borland Delphi 5.0 31658845.52 3846
Microsoft C#.net 1.0 31658845.52 3615
Microsoft Visual Basic 6.0 31658845.52 2534

Run report:

Compiled =====================

Borland Delphi 5.0
Test Count: 100000
Init -------------------------
Year: 1626
Principle: 12.00
Rate: 0.04
Results ----------------------
Principle: 31658845.52
Elapsed (ms): 3846

mbp Visual COBOL 3.6.0.8
Test Count: 100000
Init -------------------------
Year: 1626
Principle: 12.00
Rate: 0.04
Results ----------------------
Principle: 31658845.52
Elapsed (ms): 46380

Microsoft C#.net 1.0
Test Count: 100000
Init -------------------------
Year: 1626
Principle: 12.00
Rate: 0.04
Results ----------------------
Principle: 31658845.52
Elapsed (ms): 3615

Microsoft Visual Basic 6.0
Test Count: 100000
Init -------------------------
Year: 1626
Principle: 12.00
Rate: 0.04
Results ----------------------
Principle: 31658845.52
Elapsed (ms): 2534

Interpreted ==================

Regina REXX 3.2
Test Count: 100000
Init -------------------------
Year: 1626
Principle: 12.00
Rate: 0.04
Results ----------------------
Principle: 31658845.52
Elapsed (ms): 164000 +/- 1000
 #15  
09-29-03, 03:45 AM
Grinder
/* REXX */
Numeric digits 12

TestCount = 100000
InitPrinciple = 12.00
InitYear = 1626
Rate = 0.04

Multiplier = 1 + Rate
ThisYear = 2003

say
say "Regina REXX 3.2"
say " Test Count: " FORMAT(TestCount, 8, 0)
say "Init -------------------------"
say " Year: " FORMAT(InitYear, 4, 0)
say " Principle: " FORMAT(InitPrinciple, 12, 2)
say " Rate: " FORMAT(Rate, 3, 2)

/* start the clock */
/* Any ideas on how to get fractional seconds? */
Elapsed = DATE("T")

do Test = 1 to TestCount
Principle = InitPrinciple
do Year = InitYear to ThisYear - 1
Principle = FORMAT(Principle * Multiplier, , 2)
end
end

/* stop the clock */
/* Any ideas on how to get fractional seconds? */
Elapsed = 1000 * (DATE("T") - Elapsed)

say "Results ----------------------"
say " Principle: " FORMAT(Principle, 12, 2)
say " Elapsed (ms): " FORMAT(Elapsed, 6) "+/- 1000"


exit

Similar Threads
Bizarre benchmark result -- C# hundreds of times slower than Java?

While asking some Java enthusiasts what they think about C#, I came across this: [..] Reportedly, the (essentially) same program in C# is much, much slower than in...

memory/IO intensive Java benchmark

Hi, I'm looking for some Java benchmarks that are highly memory and I/O intensive, ones that would spend a lot of time in paging and disk accesses. Does anyone have any...

Benchmark Java vs. COBOL

Dear COBOL community, No, I am not anticipating, expecting anything. No flame, no rant, just a question: I wonder if there is a benchmark that compares performance...

Why is C# so slow in this benchmark vs Java

I was looking at this page [..] And noticed running the same code (Java ported to C# using the MS tool I expect) that the C# implementation is over 50% slower than Java in...


All times are GMT. The time now is 09:40 AM. | Privacy Policy