|
#1
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
> 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
|
|
|
|
|
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
|
|
|
|
|
"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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
"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
|
|
|
|
|
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
|
|
|
|
|
"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
|
|
|
|
|
> 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
|
|
|
|
|
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
|
|
|
|
|
/* 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
|