I wrote up the results of trying Dave Plummer's software drag racing on
z/OS.
The focus is mainly Java vs C++ because I do SMF processing in Java, and
people like to tell me Java is too slow. Results are here:
https://www.blackhillsoftware.com/news/2021/08/10/java-vs-c-drag-racing-on-z-os/
First episode of counting number of primes in various languages has been
uploaded to
https://www.youtube.com/c/DavesGarage/videos .
https://www.youtube.com/watch?v=tQtFdsEcK_s
Only 45 languages. 1500 languages claimed on
http://www.99-bottles-of-beer.net/
On 29/06/2021 11:14 am, David Crayford wrote:
I'm using Rocket's Python which is definitely CPython (the same as
IBMs). When the say "native" they mean it's a native z/OS port.
Interesting... I found a pull request that claims a 65-130x faster
Python implementation with details here:
On 28/06/2021 1:15 pm, Andrew Rowley wrote:
Well, I'm seeing different results on z/OS. There is no PyPy on z/OS.
I don't know. IBM describe it as a "Native Python compiler for z/OS"
so maybe it is JIT compiled? I guess it's a good thing if it is.
I'm using Rocket's Python which is
Being a bit more curious, I set //GO.SYSOUT DD DUMMY to remove the
overhead of formatting and printing, and the CPU time for the 3355440
version went to 1.10 seconds. Very impressive.
Bill
--
For IBM-MAIN subscribe /
Not being a COBOL person, I could not resist trying the prime number
COBOL program previously listed. Working on a zPDT system (based on a
rather large laptop) I tried the NA-LINE OCCURS 26214 version and this
took .14 seconds CPU, producing about 2800 lines of output. I then tried
the
On 28/06/2021 2:46 pm, David Crayford wrote:
Well, I'm seeing different results on z/OS. There is no PyPy on z/OS.
I don't know. IBM describe it as a "Native Python compiler for z/OS" so
maybe it is JIT compiled? I guess it's a good thing if it is.
--
Andrew Rowley
Black Hill Software
On 28/06/2021 12:31 pm, Andrew Rowley wrote:
On 28/06/2021 1:51 pm, David Crayford wrote:
That not particularily fast either. How can Python be faster than C?
danielspaangberg_1of2;2756;5.000862;1;algorithm=base,faithful=yes,bits=1
How did you run the Python version? From the comments it
On 28/06/2021 1:51 pm, David Crayford wrote:
That not particularily fast either. How can Python be faster than C?
danielspaangberg_1of2;2756;5.000862;1;algorithm=base,faithful=yes,bits=1
How did you run the Python version? From the comments it looks like
running it using PyPy improves the
On 28/06/2021 9:56 am, Andrew Rowley wrote:
On 26/06/2021 4:50 pm, David Crayford wrote:
That's an exaggeration. C is just over 3x faster.
C
mckoss-c830;14285;5.0;1;algorithm=wheel,faithful=yes,bits=1
The C implementations are confusing because there are various
algorithm changes as
On 25/06/2021 11:35 pm, Andrew Rowley wrote:
I set the limit to 100,000,000 (the source validates results for
multiples of 10) and got 10 passes in 5 seconds on my laptop. At
100,000,000 the bit map doesn't fit in processor cache which might be
a significant penalty. 1,000,000 gives better
On 26/06/2021 4:50 pm, David Crayford wrote:
That's an exaggeration. C is just over 3x faster.
C
mckoss-c830;14285;5.0;1;algorithm=wheel,faithful=yes,bits=1
The C implementations are confusing because there are various algorithm
changes as well, rather than just the language change.
On 26/06/2021 2:50 pm, David Crayford wrote:
On 26/06/2021 2:38 pm, David Crayford wrote:
I think the C++ compiler/library is a large part of it. On other
platforms vector was apparently a big performance improvement,
on z/OS removing it was a big improvement. So if there is something
On 26/06/2021 2:38 pm, David Crayford wrote:
I think the C++ compiler/library is a large part of it. On other
platforms vector was apparently a big performance improvement,
on z/OS removing it was a big improvement. So if there is something
smart happening there on other platforms, there
On 26/06/2021 11:59 am, Andrew Rowley wrote:
On 25/06/2021 8:58 pm, Scott Chapman wrote:
If other platforms don't JIT as quickly or aggressively, or if their
JIT compiler isn't as smart as IBM's then their results may not be
the same. Similarly, if the IBM C compiler isn't as optimized as it
On 25/06/2021 8:58 pm, Scott Chapman wrote:
If other platforms don't JIT as quickly or aggressively, or if their JIT
compiler isn't as smart as IBM's then their results may not be the same.
Similarly, if the IBM C compiler isn't as optimized as it is on other
platforms, it might underperform.
On 25/06/2021 9:26 pm, Dave Jousma wrote:
I looked at the video, and looks like he is running for 5 seconds, but cannot
tell how many prime numbers he calculated on the platforms he was testing. I
had an old COBOL program laying around from years ago that calculates prime
numbers. This
I looked at the video, and looks like he is running for 5 seconds, but cannot
tell how many prime numbers he calculated on the platforms he was testing. I
had an old COBOL program laying around from years ago that calculates prime
numbers. This morning I cranked it up to a limit of
That is a bit surprising given that it looks like that only runs for 5 seconds?
But there's not much code there and it's all in a loop. My recollection is that
the JIT compiler will step in after x repeated executions, which will happen
pretty quickly here. And the compiled code as the
I profiled the C++ code using APA. It's spending all it's time bit
twiddling and doing mod division. The Java version uses a much more
efficient implementation that uses an array of boolean's which isn't
initialized to turn the bits on.
On 25/06/2021 1:01 pm, Andrew Rowley wrote:
On
On 25/06/2021 2:34 pm, David Crayford wrote:
If you've got the XLC 2.4.1 it will will be installed in the
/usr/lpp/cbc/xlclang/exe directory. It's 64-bit only. We use this
compiler exclusively now. It's really cool and has neat features such
as type checking printf() format flags at compile
On 25/06/2021 12:44 pm, Ed Jaffe wrote:
On 6/24/2021 9:34 PM, David Crayford wrote:
If you've got the XLC 2.4.1 it will will be installed in the
/usr/lpp/cbc/xlclang/exe directory. It's 64-bit only. We use this
compiler exclusively now. It's really cool and has neat features such
as type
On 6/24/2021 9:34 PM, David Crayford wrote:
If you've got the XLC 2.4.1 it will will be installed in the
/usr/lpp/cbc/xlclang/exe directory. It's 64-bit only. We use this
compiler exclusively now. It's really cool and has neat features such
as type checking printf() format flags at compile
If you've got the XLC 2.4.1 it will will be installed in the
/usr/lpp/cbc/xlclang/exe directory. It's 64-bit only. We use this
compiler exclusively now. It's really cool and has neat features such as
type checking printf() format flags at compile time.
On 25/06/2021 12:22 pm, Andrew Rowley
On 25/06/2021 1:45 pm, David Crayford wrote:
Interesting! Try compiling using xlclang++ instead of xlc and see how
you go. xlclang++ has a far superior standard library.
I'm not sure whether it is installed on my system. I tried it and it
fails, I think it is looking for module CLCDRVR. Any
Interesting! Try compiling using xlclang++ instead of xlc and see how
you go. xlclang++ has a far superior standard library.
Nothing matches the speed of C :)
mckoss-c830;14259;5.0;1;algorithm=wheel,faithful=yes,bits=1
On 25/06/2021 10:22 am, Andrew Rowley wrote:
Dave Plummer has a series of
26 matches
Mail list logo
