In article
<······················@dyn1-tnt1-174.kalamazoo.mi.ameritech.net>,
·····@metrowerks.com (MW Ron) wrote:
>In article <··································@206.82.216.1>,
>·······@quicksilver.com (Rob Barris) wrote:
[in response to MWRon's sig "CW Pro 4.0 C++ 30% edge in Tak benchmark
over VC++ 6.0"]
>
>
>> What is the Tak benchmark?
>
>ZD has an article about it online
>
>http://www.zdnet.com/zdnn/content/pcwk/1339/pcwk0056.html
>
>Ron
>
It might interest both CodeWarriors as well as MCL users to know that this
benchmark runs a bit faster in Macintosh Common Lisp 4.2 (5.6 seconds for
1000 iterations) than in CodeWarrior Pro 4 for the Mac (6.2 seconds). For
comparison of times with your machines, I'm running on a 292 Mhz G3 Series
PowerBook under MacOS 8.5. I've set optimizations to generate fastest
possible code in both IDEs.
----------- lisp version --------------
(defun tak (x y z)
(declare (fixnum x y z))
(declare (optimize (speed 3) (safety 0)))
(if (not (< y x))
(the fixnum z)
(tak (the fixnum (tak (the fixnum (- x 1)) y z))
(the fixnum (tak (the fixnum (- y 1)) z x))
(the fixnum (tak (the fixnum (- z 1)) x y)))))
----------- lisp listener output ------------
? (time (dotimes (n 1000) (tak 18 12 6)))
(DOTIMES (N 1000) (TAK 18 12 6)) took 5,606 milliseconds (5.606 seconds) to run.
Of that, 84 milliseconds (0.084 seconds) were spent in The Cooperative
Multitasking Experience.
NIL
----------------------------
By the way, "?" is the lisp toplevel prompt in MCL and NIL is the return
value of DOTIMES,not TAK. (TAK 18 12 6) returns 7, as it should:
? (tak 18 12 6)
7
----------- c++ version -------------
#include <iostream>
#include <stdlib.h>
#include <SegLoad.h>
#include <events.h>
#include <time.h>
using namespace std; //introduces namespace std
int tak(int x, int y, int z)
{
if (y >= x) {
return z;
} else {
return tak(tak(x-1,y,z), tak(y-1,z,x), tak(z-1,x,y));
}
}
int main()
{
int numberOfIterations;
unsigned long tickstart, tickend;
float result;
cout << "This is the Tak benchmark." << endl << endl;
cout << "Please enter the number of times to run tak:" << endl << endl;
cin >> numberOfIterations;
tickstart = TickCount();
for(int i = 1; i <= numberOfIterations; i ++)
tak(18, 12, 6);
tickend = TickCount();
result = ((float) tickend - (float) tickstart);
cout << "\nThis benchmark took " << ( result/ 60) << " seconds to run.";
return 0;
}
----------- c++ console output -----------------
This is the Tak benchmark.
Please enter the number of times to run tak:
1000
This benchmark took 6.23333 seconds to run.
----------------------------------------
--
Raffael Cavallaro
In article <························@raffaele.ne.mediaone.net>,
Raffael Cavallaro <·······@mediaone.net> wrote:
>In article
><······················@dyn1-tnt1-174.kalamazoo.mi.ameritech.net>,
>·····@metrowerks.com (MW Ron) wrote:
>
>>In article <··································@206.82.216.1>,
>>·······@quicksilver.com (Rob Barris) wrote:
>
>[in response to MWRon's sig "CW Pro 4.0 C++ 30% edge in Tak benchmark
>over VC++ 6.0"]
>>
>>
>>> What is the Tak benchmark?
>>
>>ZD has an article about it online
>>
>>http://www.zdnet.com/zdnn/content/pcwk/1339/pcwk0056.html
>>
>>Ron
>>
>
>
>It might interest both CodeWarriors as well as MCL users to know that this
>benchmark runs a bit faster in Macintosh Common Lisp 4.2 (5.6 seconds for
>1000 iterations) than in CodeWarrior Pro 4 for the Mac (6.2 seconds). For
>comparison of times with your machines, I'm running on a 292 Mhz G3 Series
>PowerBook under MacOS 8.5. I've set optimizations to generate fastest
>possible code in both IDEs.
>
And it runs faster still under MacGambit-C 3.0, taking 5.0 seconds on
my PowerPC 6500 at 225 Mhz, while the C++ version takes 10.7
seconds. MacGambit-C is a Scheme-to-C compiler, and the resulting
code was compiled with Codewarrior Pro 4 with global optimization
level 2. (Global optimization level 5 was used for the C++ version,
since it generated slightly faster code.)
Brad Lucier ······@math.purdue.edu
The Scheme code follows:
(declare (standard-bindings) (extended-bindings) (not safe) (fixnum)
(block) (not interrupts-enabled))
(define (tak x y z)
(if (not (< y x))
z
(tak (tak (- x 1) y z)
(tak (- y 1) z x)
(tak (- z 1) x y))))
(define (test-tak n)
(do ((i 0 (+ i 1)))
((= i n) (void))
(tak 18 12 6)))
Which was run as:
> (time (test-tak 1000))
(time (test-tak 1000))
5000 ms real time
4850 ms cpu time (4850 user, 0 system)
no collections
no bytes allocated
no minor faults
no major faults
In article <··········@arthur.cs.purdue.edu>, ···@cs.purdue.edu (Bradley J
Lucier) wrote:
>And it runs faster still under MacGambit-C 3.0, taking 5.0 seconds on
>my PowerPC 6500 at 225 Mhz, while the C++ version takes 10.7
>seconds. MacGambit-C is a Scheme-to-C compiler, and the resulting
>code was compiled with Codewarrior Pro 4 with global optimization
>level 2. (Global optimization level 5 was used for the C++ version,
>since it generated slightly faster code.)
Sinced MacGambit-C is ultimately compiling to C, which is then compiled by
CodeWarrior, this would suggest that CodeWarrior C++ has an approximately
100% greater function call overhead than CodeWarior C. (The Takeuchi
benchmark is a function call overhead benchmark).
Raf
--
Raffael Cavallaro
In article <··········@arthur.cs.purdue.edu>, ···@cs.purdue.edu (Bradley J
Lucier) wrote:
>And it runs faster still under MacGambit-C 3.0, taking 5.0 seconds on
>my PowerPC 6500 at 225 Mhz, while the C++ version takes 10.7
>seconds. MacGambit-C is a Scheme-to-C compiler, and the resulting
>code was compiled with Codewarrior Pro 4 with global optimization
>level 2. (Global optimization level 5 was used for the C++ version,
>since it generated slightly faster code.)
To a certain extent comparing MacGambit-C to either C++ or MCL is a bit
misleading. In MCL you get the entire CLOS implimentation, with generic
functions, etc. In CodeWarrior C++ you get an entire C++ implimentation
with all its object oriented capabilites.
In Gambit-C, you get Scheme, which has no object system and the overhead
that entails. This can be seen as an asset, if you want a lean, fast
development system, or as a deficit, if you want the OOP facilities that
CLOS or C++ provide.
Raf
--
Raffael Cavallaro
In article <························@raffaele.ne.mediaone.net>,
·······@mediaone.net (Raffael Cavallaro) wrote:
> In Gambit-C, you get Scheme, which has no object system and the overhead
> that entails. This can be seen as an asset, if you want a lean, fast
> development system, or as a deficit, if you want the OOP facilities that
> CLOS or C++ provide.
Should a plain C program, compiled under a C++ compiler, run any slower?
Where would this run-time overhead come from?
Further, should the Tak benchmark, as coded in plain C, run any slower
under a C++ compiler?
Rob
In article <··································@206.82.216.1>,
·······@quicksilver.com (Rob Barris) wrote:
> Should a plain C program, compiled under a C++ compiler, run any slower?
>Where would this run-time overhead come from?
Actually, this thread was finished off the newsgroups by Brad Lucier.
A: No, the C++ object system incurrs no overhead in the compiled version
under CodeWarrior (my befuddled musings notwithstanding). This was
verified by Brad who looked at the generated code. The C/C++ code *is*
however, slower than the scheme version compiled to C. Why?
"The difference seems to be caused by some unrolling of the
tail recursion in tak by the Gambit-C compiler, by using bgt rather than
bl, and some other small things that make a difference. "
- Brad Lucier
>
> Further, should the Tak benchmark, as coded in plain C, run any slower
>under a C++ compiler?
As it turns out, if you code this benchmark in "plain C," meaning
human-readable C, it will run slower than if you code it in plain scheme,
and let Gambit-C generate optimal, but not very readable (should I say
"not very expressive"), C code. In other words, if you just code it as:
int tak(int x, int y, int z)
{
if (y >= x) {
return z;
} else {
return tak(tak(x-1,y,z), tak(y-1,z,x), tak(z-1,x,y));
}
}
You won't get code as fast as letting Gambit-C do it's thing based on the
equivalent scheme code:
(declare (standard-bindings) (extended-bindings) (not safe) (fixnum)
(block) (not interrupts-enabled))
(define (tak x y z)
(if (not (< y x))
z
(tak (tak (- x 1) y z)
(tak (- y 1) z x)
(tak (- z 1) x y))))
Which suggests that the Gambit-C compiler does excellent tail-recursion
optimization (which one would expect to be a focus of a good scheme
compiler - it's required by the scheme standard) - even better than an
excellent commercial C/C++ compiler.
Raf
--
Raffael Cavallaro