On Tuesday, July 6, 2021 at 10:08:27 PM UTC+3, Kent Dickey wrote:
> In article <80ac50a0-dde2-4a66...@googlegroups.com>,
> Michael S <already...@yahoo.com> wrote:
> >On Tuesday, July 6, 2021 at 7:16:01 PM UTC+3, Branimir Maksimovic wrote:
> >> On 2021-07-06, Michael S <already...@yahoo.com> wrote:
> >> > I can believe that M1@3.2 GHz/Rosetta is able to run x64 software as
> >fast as i3-8100B but have trouble believing that it could match i7-8700B
> >either in single thread or in multithread throughput. Unless, of course,
> >absolute majority of run time spent in native libraries.
> >> You don't count that M1 is ~25-33% faster single core then any x86 :P
> >
> >I took it into account.
> >
> >Besides, while it's true for x86 CPUs in prev-gen Mac-Mini it's not true
> >for *any* x86.
> >M1 is slower than top Zen3 bins and about the same or a little slower
> >than top Comet Lake.
> >Probably somewhat slower than top Tiger Lake, but that comparison is
> >rather close.
> >Probably, measurably slower than top Rocket Lake, but I didn't look at
> >Rocket Lake closely.
> I have a Mac Mini M1, and it seems fast--very fast for some workloads (hard to
> predict branches, or working set in the 100-200KB range). It is not the
> fastest CPU on the planet, but it likely is the fastest laptop CPU. At < 10W
> at the AC plug it compares pretty favorably to 60W CPUs. If you have a
> relatively short benchmark (say, one file, C or C++, can be run from the Unix
> command line, doesn't require me to install anything else, should run in less
> than 5 minutes), I can compile it and run it for you, and then you can compare
> those results to any system you like. I don't think comparing optimized AVX
> is going to be useful, but simple integer or floating point algorithms would
> be best.
>
> Kent

The Euler-413 challenge that we discussed today in comp.lang.c for nDigits=11 should run in about 3 minutes.
But who is going to test on the fastest Zen3 ?
I have Ryzen 7 5800H at work, it's pretty fast and with single thread easily blows away 4.25GHz Skylake, but it's much slower than likes of 5900X.

Code:
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

static unsigned long long oneChildsInRange(int nDigits);
int main(int argz, char** argv)
{ if (argz < 2) {
fprintf(stderr, "Usage:\n%s nDigits\n", argv[0]);
return 1;
}

char* endp;
int nDigits = strtol(argv[1], &endp, 0);
if (endp == argv[1]) {
fprintf(stderr, "Bad nDigits argument '%s'. Not a number.\n", argv[1]);
return 1;
}

if (nDigits < 5 || nDigits > 19) {
fprintf(stderr, "Please specify nDigits argument in range [5:19].\n");
return 1;
}

printf("%2d %20llu\n", nDigits, oneChildsInRange(nDigits));
return 0;
}

static int countChilds(const uint8_t *digits, int nDigits, const uint8_t *remTab)
{ int nChilds = 0;
for (int beg = 0; beg < nDigits; ++beg) {
unsigned r = 0;
for (int end = beg; end < nDigits; ++end) {
r = remTab[r*10+digits[end]];
nChilds += (r == 0);
}
if (nChilds > 1)
break; // we don't try to distinguish between cases of (nChilds > 1)
}
return nChilds;
}

static int countChilds2(
const uint8_t *prefix, int prefixlen,
const uint8_t *suffix, int suffixlen,
const uint8_t *remTab,
int nChilds0)
{ int nChilds = nChilds0;
for (int prefix_i = 0; prefix_i < prefixlen; ++prefix_i) {
unsigned r = prefix[prefix_i];
for (int i = 0; i < suffixlen; ++i) {
r = remTab[r*10+suffix[i]];
nChilds += (r == 0);
}
if (nChilds > 1)
break; // we don't try to distinguish between cases of (nChilds > 1)
}
return nChilds;
}

static void preprocessPrefix(uint8_t *dst, const uint8_t *src, int nDigits, const uint8_t *remTab)
{ for (int beg = 0; beg < nDigits; ++beg) {
unsigned r = 0;
for (int end = beg; end < nDigits; ++end)
r = remTab[r*10+src[end]];
dst[beg] = r;
}
}

static unsigned long long intpow(unsigned base, int pow)
{ unsigned long long prod = 1;
for (int k = 0; k < pow; ++k)
prod *= base;
return prod;
}

static void to_digits(uint8_t* dst, unsigned long long x, int nDigits)
{ for (int k = 0; k < nDigits; ++k) {
dst[nDigits-1-k] = x % 10;
x /= 10;
}
}

static unsigned long long oneChildsInRange(int nDigits)
{ // initialize look-up table
uint8_t remTab[200];
for (int i = 0; i < nDigits*10; ++i)
remTab[i] = i % nDigits;

// initialize table of suffixes
uint8_t suffixes[10000][4];
int nSuff0 = 0;
int nSuff1 = 0;
for (int i = 0; i < 10000; ++i) {
uint8_t suffix[4];
to_digits(suffix, i, 4); // convert suffix to array of digits
int nc = countChilds(suffix, 4, remTab);
if (nc < 2) {
if (nc == 0) {
memcpy(suffixes[nSuff0], suffix, sizeof(suffixes[0]));
++nSuff0;
} else { // nc==1
memcpy(suffixes[9999-nSuff1], suffix, sizeof(suffixes[0])); // store starting from the end of array
++nSuff1;
}
}
}
if (nSuff1 > 0) // make suffixes[] array continuous
memmove(suffixes[nSuff0], suffixes[10000-nSuff1], nSuff1*sizeof(suffixes[0]));

unsigned long long cnt = 0;
unsigned long long pref0 = intpow(10, nDigits-5);
for (unsigned long long pref = pref0; pref < pref0*10; ++pref) {
uint8_t prefix[20];
to_digits(prefix, pref, nDigits-4); // convert prefix to array of digits
int nc = countChilds(prefix, nDigits-4, remTab);
if (nc < 2) {
uint8_t processed_prefix[20];
preprocessPrefix(processed_prefix, prefix, nDigits-4, remTab);
for (int i = 0; i < nSuff0; ++i) // concatenate suffix with 0 children to prefix with 0 or 1 children
cnt += (countChilds2(processed_prefix, nDigits-4, suffixes[i], 4, remTab, nc)==1);
if (nc == 0) {
for (int i = nSuff0; i < nSuff0+nSuff1; ++i) // concatenate suffix with 1 child to prefix with 0 children
cnt += (countChilds2(processed_prefix, nDigits-4, suffixes[i], 4, remTab, 1)==1);
}
}
}

return cnt;
}

On 2021-07-06, Michael S <already5chosen@yahoo.com> wrote:
> On Tuesday, July 6, 2021 at 10:08:27 PM UTC+3, Kent Dickey wrote:
>> In article <80ac50a0-dde2-4a66...@googlegroups.com>,
>> Michael S <already...@yahoo.com> wrote:
>> >On Tuesday, July 6, 2021 at 7:16:01 PM UTC+3, Branimir Maksimovic wrote:
>> >> On 2021-07-06, Michael S <already...@yahoo.com> wrote:
>> >> > I can believe that M1@3.2 GHz/Rosetta is able to run x64 software as
>> >fast as i3-8100B but have trouble believing that it could match i7-8700B
>> >either in single thread or in multithread throughput. Unless, of course,
>> >absolute majority of run time spent in native libraries.
>> >> You don't count that M1 is ~25-33% faster single core then any x86 :P
>> >
>> >I took it into account.
>> >
>> >Besides, while it's true for x86 CPUs in prev-gen Mac-Mini it's not true
>> >for *any* x86.
>> >M1 is slower than top Zen3 bins and about the same or a little slower
>> >than top Comet Lake.
>> >Probably somewhat slower than top Tiger Lake, but that comparison is
>> >rather close.
>> >Probably, measurably slower than top Rocket Lake, but I didn't look at
>> >Rocket Lake closely.
>> I have a Mac Mini M1, and it seems fast--very fast for some workloads (hard to
>> predict branches, or working set in the 100-200KB range). It is not the
>> fastest CPU on the planet, but it likely is the fastest laptop CPU. At < 10W
>> at the AC plug it compares pretty favorably to 60W CPUs. If you have a
>> relatively short benchmark (say, one file, C or C++, can be run from the Unix
>> command line, doesn't require me to install anything else, should run in less
>> than 5 minutes), I can compile it and run it for you, and then you can compare
>> those results to any system you like. I don't think comparing optimized AVX
>> is going to be useful, but simple integer or floating point algorithms would
>> be best.
>>
>> Kent
>
>
> The Euler-413 challenge that we discussed today in comp.lang.c for nDigits=11 should run in about 3 minutes.

bmaxa@Branimirs-Air euler % time ./euler413 11
11 71101800
../euler413 11 62.07s user 0.16s system 99% cpu 1:02.39 total

Minute on M1...

> But who is going to test on the fastest Zen3 ?

Someone with fastest Zen3? :P

On Wednesday, July 7, 2021 at 2:39:14 AM UTC+3, Branimir Maksimovic wrote:
> On 2021-07-06, Michael S <already...@yahoo.com> wrote:
> > On Tuesday, July 6, 2021 at 10:08:27 PM UTC+3, Kent Dickey wrote:
> >> In article <80ac50a0-dde2-4a66...@googlegroups.com>,
> >> Michael S <already...@yahoo.com> wrote:
> >> >On Tuesday, July 6, 2021 at 7:16:01 PM UTC+3, Branimir Maksimovic wrote:
> >> >> On 2021-07-06, Michael S <already...@yahoo.com> wrote:
> >> >> > I can believe that M1@3.2 GHz/Rosetta is able to run x64 software as
> >> >fast as i3-8100B but have trouble believing that it could match i7-8700B
> >> >either in single thread or in multithread throughput. Unless, of course,
> >> >absolute majority of run time spent in native libraries.
> >> >> You don't count that M1 is ~25-33% faster single core then any x86 :P
> >> >
> >> >I took it into account.
> >> >
> >> >Besides, while it's true for x86 CPUs in prev-gen Mac-Mini it's not true
> >> >for *any* x86.
> >> >M1 is slower than top Zen3 bins and about the same or a little slower
> >> >than top Comet Lake.
> >> >Probably somewhat slower than top Tiger Lake, but that comparison is
> >> >rather close.
> >> >Probably, measurably slower than top Rocket Lake, but I didn't look at
> >> >Rocket Lake closely.
> >> I have a Mac Mini M1, and it seems fast--very fast for some workloads (hard to
> >> predict branches, or working set in the 100-200KB range). It is not the
> >> fastest CPU on the planet, but it likely is the fastest laptop CPU. At < 10W
> >> at the AC plug it compares pretty favorably to 60W CPUs. If you have a
> >> relatively short benchmark (say, one file, C or C++, can be run from the Unix
> >> command line, doesn't require me to install anything else, should run in less
> >> than 5 minutes), I can compile it and run it for you, and then you can compare
> >> those results to any system you like. I don't think comparing optimized AVX
> >> is going to be useful, but simple integer or floating point algorithms would
> >> be best.
> >>
> >> Kent
> >
> >
> > The Euler-413 challenge that we discussed today in comp.lang.c for nDigits=11 should run in about 3 minutes.
> bmaxa@Branimirs-Air euler % time ./euler413 11
> 11 71101800
> ./euler413 11 62.07s user 0.16s system 99% cpu 1:02.39 total
>

Sorry, my mistake.
I had another variant of algorithm that took 3 minutes. This one is indeed much faster.
1m15.640s on Xeon E-2176G underclocked to 4.25GHz.

>
> Minute on M1...
> > But who is going to test on the fastest Zen3 ?
> Someone with fastest Zen3? :P

On 2021-07-06, Michael S <already5chosen@yahoo.com> wrote:
> On Wednesday, July 7, 2021 at 2:39:14 AM UTC+3, Branimir Maksimovic wrote:
>> On 2021-07-06, Michael S <already...@yahoo.com> wrote:
>> > On Tuesday, July 6, 2021 at 10:08:27 PM UTC+3, Kent Dickey wrote:
>> >> In article <80ac50a0-dde2-4a66...@googlegroups.com>,
>> >> Michael S <already...@yahoo.com> wrote:
>> >> >On Tuesday, July 6, 2021 at 7:16:01 PM UTC+3, Branimir Maksimovic wrote:
>> >> >> On 2021-07-06, Michael S <already...@yahoo.com> wrote:
>> >> >> > I can believe that M1@3.2 GHz/Rosetta is able to run x64 software as
>> >> >fast as i3-8100B but have trouble believing that it could match i7-8700B
>> >> >either in single thread or in multithread throughput. Unless, of course,
>> >> >absolute majority of run time spent in native libraries.
>> >> >> You don't count that M1 is ~25-33% faster single core then any x86 :P
>> >> >
>> >> >I took it into account.
>> >> >
>> >> >Besides, while it's true for x86 CPUs in prev-gen Mac-Mini it's not true
>> >> >for *any* x86.
>> >> >M1 is slower than top Zen3 bins and about the same or a little slower
>> >> >than top Comet Lake.
>> >> >Probably somewhat slower than top Tiger Lake, but that comparison is
>> >> >rather close.
>> >> >Probably, measurably slower than top Rocket Lake, but I didn't look at
>> >> >Rocket Lake closely.
>> >> I have a Mac Mini M1, and it seems fast--very fast for some workloads (hard to
>> >> predict branches, or working set in the 100-200KB range). It is not the
>> >> fastest CPU on the planet, but it likely is the fastest laptop CPU. At < 10W
>> >> at the AC plug it compares pretty favorably to 60W CPUs. If you have a
>> >> relatively short benchmark (say, one file, C or C++, can be run from the Unix
>> >> command line, doesn't require me to install anything else, should run in less
>> >> than 5 minutes), I can compile it and run it for you, and then you can compare
>> >> those results to any system you like. I don't think comparing optimized AVX
>> >> is going to be useful, but simple integer or floating point algorithms would
>> >> be best.
>> >>
>> >> Kent
>> >
>> >
>> > The Euler-413 challenge that we discussed today in comp.lang.c for nDigits=11 should run in about 3 minutes.
>> bmaxa@Branimirs-Air euler % time ./euler413 11
>> 11 71101800
>> ./euler413 11 62.07s user 0.16s system 99% cpu 1:02.39 total
>>
>
> Sorry, my mistake.
> I had another variant of algorithm that took 3 minutes. This one is indeed much faster.
> 1m15.640s on Xeon E-2176G underclocked to 4.25GHz.

M1 runs at 3.2Ghz max. This one consumes 6W when executing your proggy :P
>
>>

--
something dumb

On 7/4/2021 5:05 AM, Branimir Maksimovic wrote:
> Fantastic chip, blows away my 2700X in single thread.
> 3950 scimark2 score vs 3050 2700X.
> But, chip scales badly. Tried WCG and when running 2 threads no slowdown.
> However with 3 threads slowdown iz 25%, with 4 threads slowdown is ~50%.
> So chip is actually like i3 with two cores+HT.
> But it is much faster as single thread perfomance is fantastic.
> What is puzzling is that 5-7 thread does not have such slowdown,
> that is on low power cores performance loss per thread is more like 10-15%.
>

Can you try to run the following program, and post your results? C++17...

https://pastebin.com/raw/CYZ78gVj

Should compile right up. Its a poor mans RCU, with debugging variables
turned on for a sanity check. Basically, a proxy collector to be able to
get RCU like abilities using 100% standard C++.

On 2021-07-07, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 7/4/2021 5:05 AM, Branimir Maksimovic wrote:
>> Fantastic chip, blows away my 2700X in single thread.
>> 3950 scimark2 score vs 3050 2700X.
>> But, chip scales badly. Tried WCG and when running 2 threads no slowdown.
>> However with 3 threads slowdown iz 25%, with 4 threads slowdown is ~50%.
>> So chip is actually like i3 with two cores+HT.
>> But it is much faster as single thread perfomance is fantastic.
>> What is puzzling is that 5-7 thread does not have such slowdown,
>> that is on low power cores performance loss per thread is more like 10-15%.
>>
>
> Can you try to run the following program, and post your results? C++17...
>
> https://pastebin.com/raw/CYZ78gVj
>
> Should compile right up. Its a poor mans RCU, with debugging variables
> turned on for a sanity check. Basically, a proxy collector to be able to
> get RCU like abilities using 100% standard C++.
bmaxa@Branimirs-Air Chris % time ./test1
Chris M. Thomassons Proxy Collector Port ver .0.0.2...
_______________________________________

Booting threads...
Threads running...
Threads completed!

node_allocations = 92400000
node_deallocations = 92400000

dtor_collect = 249854
release_collect = 905
quiesce_complete = 250759
quiesce_begin = 250759
quiesce_complete_nodes = 92400000

Test Completed!

../test1 136.73s user 1.26s system 657% cpu 20.992 total

--
something dumb

In article <187875de-0cd7-4e6e-b4a9-71a9eb1f5527n@googlegroups.com>,
Michael S <already5chosen@yahoo.com> wrote:
>On Tuesday, July 6, 2021 at 10:08:27 PM UTC+3, Kent Dickey wrote:
>> I have a Mac Mini M1, and it seems fast--very fast for some workloads
>(hard to
>> predict branches, or working set in the 100-200KB range). It is not the
>> fastest CPU on the planet, but it likely is the fastest laptop CPU. At < 10W
>> at the AC plug it compares pretty favorably to 60W CPUs. If you have a
>> relatively short benchmark (say, one file, C or C++, can be run from the Unix
>> command line, doesn't require me to install anything else, should run in less
>> than 5 minutes), I can compile it and run it for you, and then you can
>compare
>> those results to any system you like. I don't think comparing optimized AVX
>> is going to be useful, but simple integer or floating point algorithms would
>> be best.
>>
>> Kent
>
>
>The Euler-413 challenge that we discussed today in comp.lang.c for
>nDigits=11 should run in about 3 minutes.
>But who is going to test on the fastest Zen3 ?
>I have Ryzen 7 5800H at work, it's pretty fast and with single thread
>easily blows away 4.25GHz Skylake, but it's much slower than likes of
>5900X.
>
>Code:
[snipped].

I compiled and ran it on my Mac Mini M1 with 8GB of memory (it's 3.2GHz,
I've measured it by reading the CPU timers, Apple doesn't publicly list
the frequency):

---
m1-mini-bash$ cc -O2 -o michaels1 michaels1.c
m1-mini-bash$ time ./michaels1 11
11 71101800

real 0m48.764s
user 0m48.507s
sys 0m0.071s
---

(I've also run it multiple times, later runs get as low at 48.493s real).

The same code on my iMac Pro (3.0GHz 10-core Intel Xeon W, Turbo to 4.5GHz,
thought to be Intel Xeon W-2150B, so not new, but not really old either, and
not a laptop CPU):

---
imacpro$ time ./michaels1 11
11 71101800

real 1m39.070s
user 1m38.530s
sys 0m0.305s
---

I tried compiling -O3, made no real difference (-O3 was slightly slower on
my Intel Mac).

So the Mac Mini M1 is almost exactly twice as fast as my iMac Pro for this
code.

I tried running 4 copies at once in the simplest way possible:

time ./michaels1 11 & time ./michaels1 11 & time ./michaels1 11 & \
time ./michaels1 11

Each run took about 52.08sec real time. No fans, I don't feel any heat.
On my iMac Pro, doing the same 4 runs, each run took about 1m41.5sec,
and the fans came on.

And I copied over the x86_64 binary which I compiled on my iMacPro to the
Mac Mini M1.

---
m1-mini-bash$ time ./michaels1x86 11
11 71101800

real 1m14.517s
user 1m13.896s
sys 0m0.287s
---

This is some of the biggest slowdown I've seen with the JIT translation. It
still runs x86 faster than my actual x86.

Summary results:
Mac Mini M1: 48.764s
Mac Mini M1 JIT x86: 74.517s
iMac Pro 4.5GHz: 99.070s

Kent

In article <sc2qtq$5la$1@gioia.aioe.org>,
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>On 7/4/2021 5:05 AM, Branimir Maksimovic wrote:
>> Fantastic chip, blows away my 2700X in single thread.
>> 3950 scimark2 score vs 3050 2700X.
>> But, chip scales badly. Tried WCG and when running 2 threads no slowdown.
>> However with 3 threads slowdown iz 25%, with 4 threads slowdown is ~50%.
>> So chip is actually like i3 with two cores+HT.
>> But it is much faster as single thread perfomance is fantastic.
>> What is puzzling is that 5-7 thread does not have such slowdown,
>> that is on low power cores performance loss per thread is more like 10-15%.
>>
>
>Can you try to run the following program, and post your results? C++17...
>
>https://pastebin.com/raw/CYZ78gVj
>
>Should compile right up. Its a poor mans RCU, with debugging variables
>turned on for a sanity check. Basically, a proxy collector to be able to
>get RCU like abilities using 100% standard C++.

This looks like a program which spawns dozens of threads. The M1 chip only
has 8 cores (4 fast, 4 slow), so I'm not really sure what this benchmark
shows. It may be that it does better with fewer cores (less contention),
it may do worse.

Here's my output:

---
m1-mini-bash$ c++ -O2 -std=c++17 -o thomassons.rcu thomassons.rcu.cpp
m1-mini-bash$ time ./thomassons.rcu
Chris M. Thomassons Proxy Collector Port ver .0.0.2...
_______________________________________

Booting threads...
Threads running...
Threads completed!

node_allocations = 92400000
node_deallocations = 92400000

dtor_collect = 3
release_collect = 169
quiesce_complete = 172
quiesce_begin = 172
quiesce_complete_nodes = 92400000

Test Completed!

real 0m24.240s
user 3m11.190s
sys 0m0.857s
---

So 24.240 seconds real time.

I also ran it on my iMac Pro x86 (4.5GHz Turbo, 10 cores):

---
imacpro-bash$ clang++ -O2 -std=c++17 -o thomassons.rcu thomassons.rcu.cpp
imacpro-bash$ time ./thomassons.rcu
Chris M. Thomassons Proxy Collector Port ver .0.0.2...
_______________________________________

Booting threads...
Threads running...
Threads completed!

node_allocations = 92400000
node_deallocations = 92400000

dtor_collect = 11
release_collect = 231
quiesce_complete = 242
quiesce_begin = 242
quiesce_complete_nodes = 92400000

Test Completed!

real 0m27.370s
user 8m46.058s
sys 0m3.432s
---

Kent

On Wednesday, July 7, 2021 at 7:49:42 AM UTC+3, Kent Dickey wrote:
> In article <187875de-0cd7-4e6e...@googlegroups.com>,
> Michael S <already...@yahoo.com> wrote:
> >On Tuesday, July 6, 2021 at 10:08:27 PM UTC+3, Kent Dickey wrote:
> >> I have a Mac Mini M1, and it seems fast--very fast for some workloads
> >(hard to
> >> predict branches, or working set in the 100-200KB range). It is not the
> >> fastest CPU on the planet, but it likely is the fastest laptop CPU. At < 10W
> >> at the AC plug it compares pretty favorably to 60W CPUs. If you have a
> >> relatively short benchmark (say, one file, C or C++, can be run from the Unix
> >> command line, doesn't require me to install anything else, should run in less
> >> than 5 minutes), I can compile it and run it for you, and then you can
> >compare
> >> those results to any system you like. I don't think comparing optimized AVX
> >> is going to be useful, but simple integer or floating point algorithms would
> >> be best.
> >>
> >> Kent
> >
> >
> >The Euler-413 challenge that we discussed today in comp.lang.c for
> >nDigits=11 should run in about 3 minutes.
> >But who is going to test on the fastest Zen3 ?
> >I have Ryzen 7 5800H at work, it's pretty fast and with single thread
> >easily blows away 4.25GHz Skylake, but it's much slower than likes of
> >5900X.
> >
> >Code:
> [snipped].
>
> I compiled and ran it on my Mac Mini M1 with 8GB of memory (it's 3.2GHz,
> I've measured it by reading the CPU timers, Apple doesn't publicly list
> the frequency):
>
> ---
> m1-mini-bash$ cc -O2 -o michaels1 michaels1.c
> m1-mini-bash$ time ./michaels1 11
> 11 71101800
>
> real 0m48.764s
> user 0m48.507s
> sys 0m0.071s
> ---
>
> (I've also run it multiple times, later runs get as low at 48.493s real).
>

Fantastic.
It seems, power management on your Mac Mini is seriously better than on Mac Air of Branimir.
Judged by this, you can run this program with nDigits=12 and it will take less than 25min.

> The same code on my iMac Pro (3.0GHz 10-core Intel Xeon W, Turbo to 4.5GHz,
> thought to be Intel Xeon W-2150B, so not new, but not really old either, and
> not a laptop CPU):
>
> ---
> imacpro$ time ./michaels1 11
> 11 71101800
>
> real 1m39.070s
> user 1m38.530s
> sys 0m0.305s
> ---
>

That's disappointing.
Since 3 levels of inner loops of this program are running completely out of L1D cache, I would
expect that your Cascade Lake based Xeon-W will be exact match Hz-for-Hz of my Coffee Lake Xeon-E.
So, I expected 1m15.640 / 4.5 * 4.25 = 1m11.440s.
But then I recollected that compiler is not the same - mine is gcc and yours is clang (clang9 ?).
I recompiled with clang10.1 and it's indeed slower that way: 1m44.682s, i.e. Hz-for-Hz exactly as your result.

BTW, clang can do a little better job on this code if you specify -march=native or -march=skx or -march=cascadelake or -march=skylake or -march=haswell or -march=sandybridge or -march=nehalem or -march=znver2.. Any of this flags produce very similar output.

Then it's ~12% faster which is still much slower than gcc.

> I tried compiling -O3, made no real difference (-O3 was slightly slower on
> my Intel Mac).
>
> So the Mac Mini M1 is almost exactly twice as fast as my iMac Pro for this
> code.
>
> I tried running 4 copies at once in the simplest way possible:
>
> time ./michaels1 11 & time ./michaels1 11 & time ./michaels1 11 & \
> time ./michaels1 11
>
> Each run took about 52.08sec real time. No fans, I don't feel any heat.

Again, fantastic. Seems like cooling in Mac Mini is very good. I think it's not "no fans" but rather "slow quiet fans".

> On my iMac Pro, doing the same 4 runs, each run took about 1m41.5sec,
> and the fans came on.
>

Frequency went down to 4.35Gz. Not too bad for Cascade Lake.
More interesting what would happen when all 10 cores running.

On my Xeon-E/gcc
1p - 75.592s
2p - 75.619s
3p - 75.700s
4p - 75.775s
5p - 75.991s
6p - 78.076s

But I did it slightly differently, with script
---- begin r6
../uut 11 &
../uut 11 &
../uut 11 &
../uut 11 &
../uut 11 &
../uut 11 &
wait
-- end r6
So, I have one copy of 'time' instead of 6.

> And I copied over the x86_64 binary which I compiled on my iMacPro to the
> Mac Mini M1.
>
> ---
> m1-mini-bash$ time ./michaels1x86 11
> 11 71101800
>
> real 1m14.517s
> user 1m13.896s
> sys 0m0.287s
> ---
>
> This is some of the biggest slowdown I've seen with the JIT translation. It
> still runs x86 faster than my actual x86.
>

Very interesting. Actually, for me it's the most interesting part.
Relatively bigger slowdown should be probably expected, because none of the time is spent in native libraries.

> Summary results:
> Mac Mini M1: 48.764s
> Mac Mini M1 JIT x86: 74.517s
> iMac Pro 4.5GHz: 99.070s
>
> Kent

On 2021-07-07, Michael S <already5chosen@yahoo.com> wrote:
> On Wednesday, July 7, 2021 at 7:49:42 AM UTC+3, Kent Dickey wrote:
>> In article <187875de-0cd7-4e6e...@googlegroups.com>,
>> Michael S <already...@yahoo.com> wrote:
>> >On Tuesday, July 6, 2021 at 10:08:27 PM UTC+3, Kent Dickey wrote:
>> >> I have a Mac Mini M1, and it seems fast--very fast for some workloads
>> >(hard to
>> >> predict branches, or working set in the 100-200KB range). It is not the
>> >> fastest CPU on the planet, but it likely is the fastest laptop CPU. At < 10W
>> >> at the AC plug it compares pretty favorably to 60W CPUs. If you have a
>> >> relatively short benchmark (say, one file, C or C++, can be run from the Unix
>> >> command line, doesn't require me to install anything else, should run in less
>> >> than 5 minutes), I can compile it and run it for you, and then you can
>> >compare
>> >> those results to any system you like. I don't think comparing optimized AVX
>> >> is going to be useful, but simple integer or floating point algorithms would
>> >> be best.
>> >>
>> >> Kent
>> >
>> >
>> >The Euler-413 challenge that we discussed today in comp.lang.c for
>> >nDigits=11 should run in about 3 minutes.
>> >But who is going to test on the fastest Zen3 ?
>> >I have Ryzen 7 5800H at work, it's pretty fast and with single thread
>> >easily blows away 4.25GHz Skylake, but it's much slower than likes of
>> >5900X.
>> >
>> >Code:
>> [snipped].
>>
>> I compiled and ran it on my Mac Mini M1 with 8GB of memory (it's 3.2GHz,
>> I've measured it by reading the CPU timers, Apple doesn't publicly list
>> the frequency):
>>
>> ---
>> m1-mini-bash$ cc -O2 -o michaels1 michaels1.c
>> m1-mini-bash$ time ./michaels1 11
>> 11 71101800
>>
>> real 0m48.764s
>> user 0m48.507s
>> sys 0m0.071s
>> ---
>>
>> (I've also run it multiple times, later runs get as low at 48.493s real).
>>
>
> Fantastic.
> It seems, power management on your Mac Mini is seriously better than on Mac Air of Branimir.
> Judged by this, you can run this program with nDigits=12 and it will take less than 25min.
Now I have
bmaxa@Branimirs-Air euler % time ./euler413 11
11 71101800
../euler413 11 48.99s user 0.12s system 99% cpu 49.446 total
my CPU is non stop busy :P
probably will be even faster if I shutdown everything that works :P

>
>> The same code on my iMac Pro (3.0GHz 10-core Intel Xeon W, Turbo to 4.5GHz,
>> thought to be Intel Xeon W-2150B, so not new, but not really old either, and
>> not a laptop CPU):
>>
>> ---
>> imacpro$ time ./michaels1 11
>> 11 71101800
>>
>> real 1m39.070s
>> user 1m38.530s
>> sys 0m0.305s
>> ---
>>
>
> That's disappointing.
> Since 3 levels of inner loops of this program are running completely out of L1D cache, I would
> expect that your Cascade Lake based Xeon-W will be exact match Hz-for-Hz of my Coffee Lake Xeon-E.
> So, I expected 1m15.640 / 4.5 * 4.25 = 1m11.440s.
> But then I recollected that compiler is not the same - mine is gcc and yours is clang (clang9 ?).
> I recompiled with clang10.1 and it's indeed slower that way: 1m44.682s, i.e. Hz-for-Hz exactly as your result.
>
> BTW, clang can do a little better job on this code if you specify -march=native or -march=skx or -march=cascadelake or -march=skylake or -march=haswell or -march=sandybridge or -march=nehalem or -march=znver2. Any of this flags produce very similar output.
>
> Then it's ~12% faster which is still much slower than gcc.
>
>> I tried compiling -O3, made no real difference (-O3 was slightly slower on
>> my Intel Mac).
>>
>> So the Mac Mini M1 is almost exactly twice as fast as my iMac Pro for this
>> code.
>>
>> I tried running 4 copies at once in the simplest way possible:
>>
>> time ./michaels1 11 & time ./michaels1 11 & time ./michaels1 11 & \
>> time ./michaels1 11
>>
>> Each run took about 52.08sec real time. No fans, I don't feel any heat.
>
> Again, fantastic. Seems like cooling in Mac Mini is very good. I think it's not "no fans" but rather "slow quiet fans".
>
>> On my iMac Pro, doing the same 4 runs, each run took about 1m41.5sec,
>> and the fans came on.
>>
>
> Frequency went down to 4.35Gz. Not too bad for Cascade Lake.
> More interesting what would happen when all 10 cores running.
>
> On my Xeon-E/gcc
> 1p - 75.592s
> 2p - 75.619s
> 3p - 75.700s
> 4p - 75.775s
> 5p - 75.991s
> 6p - 78.076s
>
> But I did it slightly differently, with script
> ---- begin r6
> ./uut 11 &
> ./uut 11 &
> ./uut 11 &
> ./uut 11 &
> ./uut 11 &
> ./uut 11 &
> wait
> -- end r6
> So, I have one copy of 'time' instead of 6.
>
>> And I copied over the x86_64 binary which I compiled on my iMacPro to the
>> Mac Mini M1.
>>
>> ---
>> m1-mini-bash$ time ./michaels1x86 11
>> 11 71101800
>>
>> real 1m14.517s
>> user 1m13.896s
>> sys 0m0.287s
>> ---
>>
>> This is some of the biggest slowdown I've seen with the JIT translation. It
>> still runs x86 faster than my actual x86.
bmaxa@Branimirs-Air euler % g++ -O3 euler413.c -o euler413 -target x86_64-apple-darwin
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated]
bmaxa@Branimirs-Air euler % time ./euler413 11
11 71101800
../euler413 11 80.40s user 0.20s system 99% cpu 1:20.95 total
And this is with busy CPU :P
but I got better time with O2
bmaxa@Branimirs-Air euler % gcc -O2 euler413.c -o euler413 -target x86_64-apple-darwin
bmaxa@Branimirs-Air euler % time ./euler413 11
11 71101800
../euler413 11 75.92s user 0.18s system 96% cpu 1:18.69 total

--
something dumb

Branimir Maksimovic <branimir.maksimovic@gmail.com> writes:
>> The Euler-413 challenge that we discussed today in comp.lang.c for nDigits=11 should run in about 3 minutes.
>
>bmaxa@Branimirs-Air euler % time ./euler413 11
>11 71101800
>./euler413 11 62.07s user 0.16s system 99% cpu 1:02.39 total
>
>
>Minute on M1...
>
>> But who is going to test on the fastest Zen3 ?
>
>Someone with fastest Zen3? :P

On a 5800X (and the code compiled with gcc-10.2 -O3):

perf stat -e cycles a.out 11
11 71101800

Performance counter stats for 'a.out 11':

236931852739 cycles

49.974309558 seconds time elapsed

49.971624000 seconds user
0.000000000 seconds sys

The 5800X runs this benchmark at 4741MHz (on average), slightly above
the turbo frequency of 4700MHz.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

In article <8eb074ff-9443-4fb6-90e7-33e7c749a0fen@googlegroups.com>,
already5chosen@yahoo.com (Michael S) wrote:

> It seems, power management on your Mac Mini is seriously better
> than on Mac Air of Branimir.

Mac Minis have mains power, and fans. If you're going to run anything
computationally intensive on an M1, they're the best option at present.

John

On 2021-07-07, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Branimir Maksimovic <branimir.maksimovic@gmail.com> writes:
>>> The Euler-413 challenge that we discussed today in comp.lang.c for nDigits=11 should run in about 3 minutes.
>>
>>bmaxa@Branimirs-Air euler % time ./euler413 11
>>11 71101800
>>./euler413 11 62.07s user 0.16s system 99% cpu 1:02.39 total
>>
>>
>>Minute on M1...
>>
>>> But who is going to test on the fastest Zen3 ?
>>
>>Someone with fastest Zen3? :P
>
> On a 5800X (and the code compiled with gcc-10.2 -O3):
>
> perf stat -e cycles a.out 11
> 11 71101800
>
> Performance counter stats for 'a.out 11':
>
> 236931852739 cycles
>
> 49.974309558 seconds time elapsed
>
> 49.971624000 seconds user
> 0.000000000 seconds sys
>
> The 5800X runs this benchmark at 4741MHz (on average), slightly above
> the turbo frequency of 4700MHz.
>
> - anton
Please can you run scimark2?
https://math.nist.gov/scimark2/download.html
bmaxa@Branimirs-Air scimark2 % gcc-11 -O3 *.c -o scimark2
bmaxa@Branimirs-Air scimark2 % ./scimark2
** **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to pozo@nist.gov) **
** **
Using 2.00 seconds min time per kenel.
Composite Score: 3993.31
FFT Mflops: 3299.58 (N=1024)
SOR Mflops: 3191.51 (100 x 100)
MonteCarlo: Mflops: 445.95
Sparse matmult Mflops: 4330.37 (N=1000, nz=5000)
LU Mflops: 8699.13 (M=100, N=100)

--
something dumb

On 2021-07-07, John Dallman <jgd@cix.co.uk> wrote:
> In article <8eb074ff-9443-4fb6-90e7-33e7c749a0fen@googlegroups.com>,
> already5chosen@yahoo.com (Michael S) wrote:
>
>> It seems, power management on your Mac Mini is seriously better
>> than on Mac Air of Branimir.
>
> Mac Minis have mains power, and fans. If you're going to run anything
> computationally intensive on an M1, they're the best option at present.
>

Of course, who would run WCG 24/7 on fanless laptop :P

> John

--
something dumb

In article <YigFI.3408$Nq7.1210@fx33.iad>,
Branimir Maksimovic <branimir.maksimovic@gmail.com> wrote:
>Please can you run scimark2?
>https://math.nist.gov/scimark2/download.html
>bmaxa@Branimirs-Air scimark2 % gcc-11 -O3 *.c -o scimark2
>bmaxa@Branimirs-Air scimark2 % ./scimark2
>** **
>** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
>** for details. (Results can be submitted to pozo@nist.gov) **
>** **
>Using 2.00 seconds min time per kenel.
>Composite Score: 3993.31
>FFT Mflops: 3299.58 (N=1024)
>SOR Mflops: 3191.51 (100 x 100)
>MonteCarlo: Mflops: 445.95
>Sparse matmult Mflops: 4330.37 (N=1000, nz=5000)
>LU Mflops: 8699.13 (M=100, N=100)
>
>
>--
>something dumb

I get different numbers on my Mac Mini M1 using the default clang compiler:

---
m1-mini-bash$ unzip scimark2_1c.zip
[ snip ]
m1-mini-bash$ cc -O3 -o scimark2.O3 *.c
m1-mini-bash$ ./scimark2.O3
** **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to pozo@nist.gov) **
** **
Using 2.00 seconds min time per kenel.
Composite Score: 4008.07
FFT Mflops: 2972.29 (N=1024)
SOR Mflops: 2330.35 (100 x 100)
MonteCarlo: Mflops: 475.59
Sparse matmult Mflops: 3992.39 (N=1000, nz=5000)
LU Mflops: 10269.74 (M=100, N=100)

The MonteCarlo result is low, relative to my x86 machine.

There's a scimark4 benchmark which tries to avoid over-optimizing compilers
(I guess this benchmark didn't use all of it's results sometimes):

I get basically the same results.

---
m1-mini-bash$ unzip ../scimark4_c.zip
[ snip ]
m1-mini-bash$ cd scimark4/
m1-mini-bash$ make
Called make:
cc -O3 -funroll-loops -Wall -pedantic -ansi -c FFT.c
cc -O3 -funroll-loops -Wall -pedantic -ansi -c kernel.c
cc -O3 -funroll-loops -Wall -pedantic -ansi -c Stopwatch.c
cc -O3 -funroll-loops -Wall -pedantic -ansi -c Random.c
cc -O3 -funroll-loops -Wall -pedantic -ansi -c SOR.c
cc -O3 -funroll-loops -Wall -pedantic -ansi -c SparseCompRow.c
cc -O3 -funroll-loops -Wall -pedantic -ansi -c array.c
cc -O3 -funroll-loops -Wall -pedantic -ansi -c MonteCarlo.c
cc -O3 -funroll-loops -Wall -pedantic -ansi -c LU.c
cc -O3 -funroll-loops -Wall -pedantic -ansi -c scimark4.c
cc -O3 -funroll-loops -Wall -pedantic -ansi -o scimark4 FFT.o kernel.o Stopwatch.o Random.o SOR.o SparseCompRow.o array.o MonteCarlo.o LU.o scimark4.o -lm
clang: warning: argument unused during compilation: '-ansi' [-Wunused-command-line-argument]
m1-mini-bash$ ./scimark4
** **
** SciMark4 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to pozo@nist.gov) **
** **
Using 2.00 seconds min time per kenel.

FFT Mflops: 2999.29 (N=1024)
SOR Mflops: 2330.24 (100 x 100)
MonteCarlo: Mflops: 475.55
Sparse matmult Mflops: 3994.09 (N=1000, nz=5000)
LU Mflops: 10160.98 (M=100, N=100)

************************************
Composite Score: 3992.03
************************************

FFT reps: 131072
SOR reps: 131072
Montel Carlo reps: 268435456
Sparse MatMult repss: 1048576
LU reps: 32768

checksum: 4.3411644672159821e+05
---

Kent

On 2021-07-07, Kent Dickey <kegs@provalid.com> wrote:
> In article <YigFI.3408$Nq7.1210@fx33.iad>,
> Branimir Maksimovic <branimir.maksimovic@gmail.com> wrote:
>>Please can you run scimark2?
>>https://math.nist.gov/scimark2/download.html
>>bmaxa@Branimirs-Air scimark2 % gcc-11 -O3 *.c -o scimark2
>>bmaxa@Branimirs-Air scimark2 % ./scimark2
>>** **
>>** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
>>** for details. (Results can be submitted to pozo@nist.gov) **
>>** **
>>Using 2.00 seconds min time per kenel.
>>Composite Score: 3993.31
>>FFT Mflops: 3299.58 (N=1024)
>>SOR Mflops: 3191.51 (100 x 100)
>>MonteCarlo: Mflops: 445.95
>>Sparse matmult Mflops: 4330.37 (N=1000, nz=5000)
>>LU Mflops: 8699.13 (M=100, N=100)
>>
>>
>>--
>>something dumb
>
> I get different numbers on my Mac Mini M1 using the default clang compiler:
>
> ---
> m1-mini-bash$ unzip scimark2_1c.zip
> [ snip ]
> m1-mini-bash$ cc -O3 -o scimark2.O3 *.c
> m1-mini-bash$ ./scimark2.O3
> ** **
> ** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
> ** for details. (Results can be submitted to pozo@nist.gov) **
> ** **
> Using 2.00 seconds min time per kenel.
> Composite Score: 4008.07
> FFT Mflops: 2972.29 (N=1024)
> SOR Mflops: 2330.35 (100 x 100)
> MonteCarlo: Mflops: 475.59
> Sparse matmult Mflops: 3992.39 (N=1000, nz=5000)
> LU Mflops: 10269.74 (M=100, N=100)
>
> The MonteCarlo result is low, relative to my x86 machine.

that is quirk of clang/gcc
my rust bench:
https://github.com/bmaxa/scimark2rust

bmaxa@Branimirs-Air scimark2rust % ./target/release/scimark2
** **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to pozo@nist.gov) **
** **
Using 2.00 seconds min time per kernel
Composite Score: 3228.17
FFT Mflops: 2325.65 (N=1024)
SOR Mflops: 963.48 (100 x 100)
MonteCarlo Mflops: 2147.48
Sparse matmult Mflops: 5242.88 (N=1000, nz=5000)
LU Nflops: 5461.33 (M=100, N=100)

overal lower score, but monte carlo high.

>
> There's a scimark4
I know it has unoptimised versions of files...

benchmark which tries to avoid over-optimizing compilers
> (I guess this benchmark didn't use all of it's results sometimes):
>
> I get basically the same results.

make defauult used same versions as in scimark2.
>
>

--
something dumb

On Wednesday, July 7, 2021 at 2:16:50 AM UTC+3, Michael S wrote:
> On Tuesday, July 6, 2021 at 10:08:27 PM UTC+3, Kent Dickey wrote:
> > In article <80ac50a0-dde2-4a66...@googlegroups.com>,
> > Michael S <already...@yahoo.com> wrote:
> > >On Tuesday, July 6, 2021 at 7:16:01 PM UTC+3, Branimir Maksimovic wrote:
> > >> On 2021-07-06, Michael S <already...@yahoo.com> wrote:
> > >> > I can believe that M1@3.2 GHz/Rosetta is able to run x64 software as
> > >fast as i3-8100B but have trouble believing that it could match i7-8700B
> > >either in single thread or in multithread throughput. Unless, of course,
> > >absolute majority of run time spent in native libraries.
> > >> You don't count that M1 is ~25-33% faster single core then any x86 :P
> > >
> > >I took it into account.
> > >
> > >Besides, while it's true for x86 CPUs in prev-gen Mac-Mini it's not true
> > >for *any* x86.
> > >M1 is slower than top Zen3 bins and about the same or a little slower
> > >than top Comet Lake.
> > >Probably somewhat slower than top Tiger Lake, but that comparison is
> > >rather close.
> > >Probably, measurably slower than top Rocket Lake, but I didn't look at
> > >Rocket Lake closely.
> > I have a Mac Mini M1, and it seems fast--very fast for some workloads (hard to
> > predict branches, or working set in the 100-200KB range). It is not the
> > fastest CPU on the planet, but it likely is the fastest laptop CPU. At < 10W
> > at the AC plug it compares pretty favorably to 60W CPUs. If you have a
> > relatively short benchmark (say, one file, C or C++, can be run from the Unix
> > command line, doesn't require me to install anything else, should run in less
> > than 5 minutes), I can compile it and run it for you, and then you can compare
> > those results to any system you like. I don't think comparing optimized AVX
> > is going to be useful, but simple integer or floating point algorithms would
> > be best.
> >
> > Kent
> The Euler-413 challenge that we discussed today in comp.lang.c for nDigits=11 should run in about 3 minutes.
> But who is going to test on the fastest Zen3 ?
> I have Ryzen 7 5800H at work, it's pretty fast and with single thread easily blows away 4.25GHz Skylake, but it's much slower than likes of 5900X.
>
> Code:
> #include <stdint.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
>
> static unsigned long long oneChildsInRange(int nDigits);
> int main(int argz, char** argv)
> {
> if (argz < 2) {
> fprintf(stderr, "Usage:\n%s nDigits\n", argv[0]);
> return 1;
> }
>
> char* endp;
> int nDigits = strtol(argv[1], &endp, 0);
> if (endp == argv[1]) {
> fprintf(stderr, "Bad nDigits argument '%s'. Not a number.\n", argv[1]);
> return 1;
> }
>
> if (nDigits < 5 || nDigits > 19) {
> fprintf(stderr, "Please specify nDigits argument in range [5:19].\n");
> return 1;
> }
>
> printf("%2d %20llu\n", nDigits, oneChildsInRange(nDigits));
> return 0;
> }
>
> static int countChilds(const uint8_t *digits, int nDigits, const uint8_t *remTab)
> {
> int nChilds = 0;
> for (int beg = 0; beg < nDigits; ++beg) {
> unsigned r = 0;
> for (int end = beg; end < nDigits; ++end) {
> r = remTab[r*10+digits[end]];
> nChilds += (r == 0);
> }
> if (nChilds > 1)
> break; // we don't try to distinguish between cases of (nChilds > 1)
> }
> return nChilds;
> }
>
> static int countChilds2(
> const uint8_t *prefix, int prefixlen,
> const uint8_t *suffix, int suffixlen,
> const uint8_t *remTab,
> int nChilds0)
> {
> int nChilds = nChilds0;
> for (int prefix_i = 0; prefix_i < prefixlen; ++prefix_i) {
> unsigned r = prefix[prefix_i];
> for (int i = 0; i < suffixlen; ++i) {
> r = remTab[r*10+suffix[i]];
> nChilds += (r == 0);
> }
> if (nChilds > 1)
> break; // we don't try to distinguish between cases of (nChilds > 1)
> }
> return nChilds;
> }
>
> static void preprocessPrefix(uint8_t *dst, const uint8_t *src, int nDigits, const uint8_t *remTab)
> {
> for (int beg = 0; beg < nDigits; ++beg) {
> unsigned r = 0;
> for (int end = beg; end < nDigits; ++end)
> r = remTab[r*10+src[end]];
> dst[beg] = r;
> }
> }
>
>
> static unsigned long long intpow(unsigned base, int pow)
> {
> unsigned long long prod = 1;
> for (int k = 0; k < pow; ++k)
> prod *= base;
> return prod;
> }
>
> static void to_digits(uint8_t* dst, unsigned long long x, int nDigits)
> {
> for (int k = 0; k < nDigits; ++k) {
> dst[nDigits-1-k] = x % 10;
> x /= 10;
> }
> }
>
> static unsigned long long oneChildsInRange(int nDigits)
> {
> // initialize look-up table
> uint8_t remTab[200];
> for (int i = 0; i < nDigits*10; ++i)
> remTab[i] = i % nDigits;
>
> // initialize table of suffixes
> uint8_t suffixes[10000][4];
> int nSuff0 = 0;
> int nSuff1 = 0;
> for (int i = 0; i < 10000; ++i) {
> uint8_t suffix[4];
> to_digits(suffix, i, 4); // convert suffix to array of digits
> int nc = countChilds(suffix, 4, remTab);
> if (nc < 2) {
> if (nc == 0) {
> memcpy(suffixes[nSuff0], suffix, sizeof(suffixes[0]));
> ++nSuff0;
> } else { // nc==1
> memcpy(suffixes[9999-nSuff1], suffix, sizeof(suffixes[0])); // store starting from the end of array
> ++nSuff1;
> }
> }
> }
> if (nSuff1 > 0) // make suffixes[] array continuous
> memmove(suffixes[nSuff0], suffixes[10000-nSuff1], nSuff1*sizeof(suffixes[0]));
>
> unsigned long long cnt = 0;
> unsigned long long pref0 = intpow(10, nDigits-5);
> for (unsigned long long pref = pref0; pref < pref0*10; ++pref) {
> uint8_t prefix[20];
> to_digits(prefix, pref, nDigits-4); // convert prefix to array of digits
> int nc = countChilds(prefix, nDigits-4, remTab);
> if (nc < 2) {
> uint8_t processed_prefix[20];
> preprocessPrefix(processed_prefix, prefix, nDigits-4, remTab);
> for (int i = 0; i < nSuff0; ++i) // concatenate suffix with 0 children to prefix with 0 or 1 children
> cnt += (countChilds2(processed_prefix, nDigits-4, suffixes[i], 4, remTab, nc)==1);
> if (nc == 0) {
> for (int i = nSuff0; i < nSuff0+nSuff1; ++i) // concatenate suffix with 1 child to prefix with 0 children
> cnt += (countChilds2(processed_prefix, nDigits-4, suffixes[i], 4, remTab, 1)==1);
> }
> }
> }
>
> return cnt;
> }

In the mean time I simplified and improved this program.
With new variant nDigits=11 is no longer interesting as a benchmark (too fast), but nDigits=12 and nDigits=13 are now well suited.
On my Xeon-E they took, respectively, 9m47.099s and 1m50.575s
Code:

//-- beg
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

static unsigned long long oneChildsInRange(int nDigits);
int main(int argz, char** argv)
{ if (argz < 2) {
fprintf(stderr, "Usage:\n%s nDigits\n", argv[0]);
return 1;
}

char* endp;
int nDigits = strtol(argv[1], &endp, 0);
if (endp == argv[1]) {
fprintf(stderr, "Bad nDigits argument '%s'. Not a number.\n", argv[1]);
return 1;
}

if (nDigits < 11 || nDigits > 19) {
fprintf(stderr, "Please specify nDigits argument in range [11:19].\n");
return 1;
}

printf("%2d %20llu\n", nDigits, oneChildsInRange(nDigits));
return 0;
}

typedef struct {
uint8_t isChildTab[19+10]; // [i] = i % nDigits == 0
uint8_t x10remTab [19+10]; // [i] = (10*i) % nDigits
} tabs_t;

static unsigned long long countChildsRecursive(
int prefix_nChilds, // 0 or 1
const uint8_t prefixRem[],
int prefixlen,
const tabs_t* tabs)
{ unsigned long long cnt = 0;
for (int suffix = prefix_nChilds; suffix < 10; ++suffix) {
int nChilds = suffix ? prefix_nChilds : 1;
const uint8_t *isChild = &tabs->isChildTab[suffix];
for (int i = 0; i < prefixlen; ++i)
nChilds += isChild[prefixRem[i]];

if (nChilds < 2) {
if (tabs->isChildTab[prefixlen+1]) { // all digits processed
cnt += nChilds;
} else {
// extend prefix
uint8_t prefixRemEx[20];
for (int i = 0; i < prefixlen; ++i)
prefixRemEx[i] = tabs->x10remTab[prefixRem[i]+suffix];
prefixRemEx[prefixlen] = tabs->x10remTab[suffix];
cnt += countChildsRecursive(nChilds, prefixRemEx, prefixlen+1, tabs);
}
}
}
return cnt;
}

On Wednesday, July 7, 2021 at 1:34:55 PM UTC+3, Anton Ertl wrote:
> Branimir Maksimovic <branimir....@gmail.com> writes:
> >> The Euler-413 challenge that we discussed today in comp.lang.c for nDigits=11 should run in about 3 minutes.
> >
> >bmaxa@Branimirs-Air euler % time ./euler413 11
> >11 71101800
> >./euler413 11 62.07s user 0.16s system 99% cpu 1:02.39 total
> >
> >
> >Minute on M1...
> >
> >> But who is going to test on the fastest Zen3 ?
> >
> >Someone with fastest Zen3? :P
> On a 5800X (and the code compiled with gcc-10.2 -O3):
>
> perf stat -e cycles a.out 11
> 11 71101800
>
> Performance counter stats for 'a.out 11':
>
> 236931852739 cycles
>
> 49.974309558 seconds time elapsed
>
> 49.971624000 seconds user
> 0.000000000 seconds sys
>
> The 5800X runs this benchmark at 4741MHz (on average), slightly above
> the turbo frequency of 4700MHz.
>

5800X is certainly fast, but according to my understanding, 5900X and 5950X are faster.

> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

Branimir Maksimovic <branimir.maksimovic@gmail.com> writes:
>Please can you run scimark2?
>https://math.nist.gov/scimark2/download.html
>bmaxa@Branimirs-Air scimark2 % gcc-11 -O3 *.c -o scimark2
>bmaxa@Branimirs-Air scimark2 % ./scimark2
>** **
>** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
>** for details. (Results can be submitted to pozo@nist.gov) **
>** **
>Using 2.00 seconds min time per kenel.
>Composite Score: 3993.31
>FFT Mflops: 3299.58 (N=1024)
>SOR Mflops: 3191.51 (100 x 100)
>MonteCarlo: Mflops: 445.95
>Sparse matmult Mflops: 4330.37 (N=1000, nz=5000)
>LU Mflops: 8699.13 (M=100, N=100)

A few variations:

Ryzen 7 5800x
https://math.nist.gov/scimark2/scimark2_1c.zip
gcc -O3 *.c -lm -o scimark2-gcc10 or clang -O3 *.c -lm -o scimark2-clang11

** **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to pozo@nist.gov) **
** **
Using 2.00 seconds min time per kenel.
gcc10 clang11
Composite Score: 3938.53 3969.17
FFT Mflops: 3534.28 3308.27 (N=1024)
SOR Mflops: 2792.49 2797.77 (100 x 100)
MonteCarlo: Mflops: 864.78 853.07
Sparse matmult Mflops: 4646.79 5167.34 (N=1000, nz=5000)
LU Mflops: 7854.31 7719.41 (M=100, N=100)

The M1 is pretty good. Too bad it's only available in Apple products.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Michael S <already5chosen@yahoo.com> writes:
>On Wednesday, July 7, 2021 at 1:34:55 PM UTC+3, Anton Ertl wrote:
>> Branimir Maksimovic <branimir....@gmail.com> writes:
>> >> The Euler-413 challenge that we discussed today in comp.lang.c for nDigits=11 should run in about 3 minutes.
>> >
>> >bmaxa@Branimirs-Air euler % time ./euler413 11
>> >11 71101800
>> >./euler413 11 62.07s user 0.16s system 99% cpu 1:02.39 total
>> >
>> >
>> >Minute on M1...
>> >
>> >> But who is going to test on the fastest Zen3 ?
>> >
>> >Someone with fastest Zen3? :P
>> On a 5800X (and the code compiled with gcc-10.2 -O3):
>>
>> perf stat -e cycles a.out 11
>> 11 71101800
>>
>> Performance counter stats for 'a.out 11':
>>
>> 236931852739 cycles
>>
>> 49.974309558 seconds time elapsed
>>
>> 49.971624000 seconds user
>> 0.000000000 seconds sys
>>
>> The 5800X runs this benchmark at 4741MHz (on average), slightly above
>> the turbo frequency of 4700MHz.
>>
>
>5800X is certainly fast, but according to my understanding, 5900X and 5950X are faster.

The 5950X has 4900MHz official boost clock, so one can expect ~47.x s
for this binary (unless it is L3 or memory bound, in which case I
would not expect a speedup from the 5950X).

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Thursday, July 8, 2021 at 10:22:59 AM UTC+3, Anton Ertl wrote:
> Michael S <already...@yahoo.com> writes:
> >On Wednesday, July 7, 2021 at 1:34:55 PM UTC+3, Anton Ertl wrote:
> >> Branimir Maksimovic <branimir....@gmail.com> writes:
> >> >> The Euler-413 challenge that we discussed today in comp.lang.c for nDigits=11 should run in about 3 minutes.
> >> >
> >> >bmaxa@Branimirs-Air euler % time ./euler413 11
> >> >11 71101800
> >> >./euler413 11 62.07s user 0.16s system 99% cpu 1:02.39 total
> >> >
> >> >
> >> >Minute on M1...
> >> >
> >> >> But who is going to test on the fastest Zen3 ?
> >> >
> >> >Someone with fastest Zen3? :P
> >> On a 5800X (and the code compiled with gcc-10.2 -O3):
> >>
> >> perf stat -e cycles a.out 11
> >> 11 71101800
> >>
> >> Performance counter stats for 'a.out 11':
> >>
> >> 236931852739 cycles
> >>
> >> 49.974309558 seconds time elapsed
> >>
> >> 49.971624000 seconds user
> >> 0.000000000 seconds sys
> >>
> >> The 5800X runs this benchmark at 4741MHz (on average), slightly above
> >> the turbo frequency of 4700MHz.
> >>
> >
> >5800X is certainly fast, but according to my understanding, 5900X and 5950X are faster.
> The 5950X has 4900MHz official boost clock, so one can expect ~47.x s
> for this binary (unless it is L3 or memory bound, in which case I
> would not expect a speedup from the 5950X).
> - anton

Computations in this program are heavily L1D & arithmetic bound.
Even L2 is barely touches on Zen3 and likely not touched at all on M1.
So, I expect perfect performance scaling with CPU frequency. But expectations are not the same as measurements.

> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On 2021-07-08, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Branimir Maksimovic <branimir.maksimovic@gmail.com> writes:
>>Please can you run scimark2?
>>https://math.nist.gov/scimark2/download.html
>>bmaxa@Branimirs-Air scimark2 % gcc-11 -O3 *.c -o scimark2
>>bmaxa@Branimirs-Air scimark2 % ./scimark2
>>** **
>>** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
>>** for details. (Results can be submitted to pozo@nist.gov) **
>>** **
>>Using 2.00 seconds min time per kenel.
>>Composite Score: 3993.31
>>FFT Mflops: 3299.58 (N=1024)
>>SOR Mflops: 3191.51 (100 x 100)
>>MonteCarlo: Mflops: 445.95
>>Sparse matmult Mflops: 4330.37 (N=1000, nz=5000)
>>LU Mflops: 8699.13 (M=100, N=100)
>
> A few variations:
>
> Ryzen 7 5800x
> https://math.nist.gov/scimark2/scimark2_1c.zip
> gcc -O3 *.c -lm -o scimark2-gcc10 or clang -O3 *.c -lm -o scimark2-clang11
>
> ** **
> ** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
> ** for details. (Results can be submitted to pozo@nist.gov) **
> ** **
> Using 2.00 seconds min time per kenel.
> gcc10 clang11
> Composite Score: 3938.53 3969.17
> FFT Mflops: 3534.28 3308.27 (N=1024)
> SOR Mflops: 2792.49 2797.77 (100 x 100)
> MonteCarlo: Mflops: 864.78 853.07
> Sparse matmult Mflops: 4646.79 5167.34 (N=1000, nz=5000)
> LU Mflops: 7854.31 7719.41 (M=100, N=100)
>
> The M1 is pretty good. Too bad it's only available in Apple products.

Worse is that I can't install Linux at this time so I must suffer macOS :(
Well, I can live with that, because there is homebrew :p
working fom command line as used to, alacritty+tmux :P

>
> - anton

--
something dumb

On Wednesday, July 7, 2021 at 12:43:00 AM UTC+3, Branimir Maksimovic wrote:
> On 2021-07-06, Kent Dickey <ke...@provalid.com> wrote:
> > In article <80ac50a0-dde2-4a66...@googlegroups.com>,
> > Michael S <already...@yahoo.com> wrote:
> >>On Tuesday, July 6, 2021 at 7:16:01 PM UTC+3, Branimir Maksimovic wrote:
> >>> On 2021-07-06, Michael S <already...@yahoo.com> wrote:
> >>> > I can believe that M1@3.2 GHz/Rosetta is able to run x64 software as
> >>fast as i3-8100B but have trouble believing that it could match i7-8700B
> >>either in single thread or in multithread throughput. Unless, of course,
> >>absolute majority of run time spent in native libraries.
> >>> You don't count that M1 is ~25-33% faster single core then any x86 :P
> >>
> >>I took it into account.
> >>
> >>Besides, while it's true for x86 CPUs in prev-gen Mac-Mini it's not true
> >>for *any* x86.
> >>M1 is slower than top Zen3 bins and about the same or a little slower
> >>than top Comet Lake.
> >>Probably somewhat slower than top Tiger Lake, but that comparison is
> >>rather close.
> >>Probably, measurably slower than top Rocket Lake, but I didn't look at
> >>Rocket Lake closely.
> >
> > I have a Mac Mini M1, and it seems fast--very fast for some workloads (hard to
> > predict branches,
> Yes, my assembler doesn't work as well as on x86 ;p
> likes loop unrolling very much :p
> Got 10% just coknverting suboutine in macro and calling several times :P
> or working set in the 100-200KB range). It is not the
> > fastest CPU on the planet, but it likely is the fastest laptop CPU.
> Sorry can't gree. Blows away x86 alright.
> At < 10W
> > at the AC plug it compares pretty favorably to 60W CPUs. If you have a
> > relatively short benchmark (say, one file, C or C++, can be run from the Unix
> > command line, doesn't require me to install anything else, should run in less
> > than 5 minutes), I can compile it and run it for you, and then you can compare
> > those results to any system you like. I don't think comparing optimized AVX
> > is going to be useful, but simple integer or floating point algorithms would
> > be best.
> It can compare with optimised AVX alright :P
>

Do you want to test it?
I have a linear algebra core (Cholesky decomposition) coded in optimised AVX (Intel intrisinc) and the same algorithm in
plain C++ that can be, in theory, vectorized by good compiler.

The most interesting would be compiling for Intel Mac and then running binary through Rosetta, as Kent did for my first test.
I don't know if you can do it without Intel Mac.

> >
> > Kent
>
>
> --
> something dumb

On 2021-07-08, Michael S <already5chosen@yahoo.com> wrote:
> On Wednesday, July 7, 2021 at 12:43:00 AM UTC+3, Branimir Maksimovic wrote:
>> On 2021-07-06, Kent Dickey <ke...@provalid.com> wrote:
>> > In article <80ac50a0-dde2-4a66...@googlegroups.com>,
>> > Michael S <already...@yahoo.com> wrote:
>> >>On Tuesday, July 6, 2021 at 7:16:01 PM UTC+3, Branimir Maksimovic wrote:
>> >>> On 2021-07-06, Michael S <already...@yahoo.com> wrote:
>> >>> > I can believe that M1@3.2 GHz/Rosetta is able to run x64 software as
>> >>fast as i3-8100B but have trouble believing that it could match i7-8700B
>> >>either in single thread or in multithread throughput. Unless, of course,
>> >>absolute majority of run time spent in native libraries.
>> >>> You don't count that M1 is ~25-33% faster single core then any x86 :P
>> >>
>> >>I took it into account.
>> >>
>> >>Besides, while it's true for x86 CPUs in prev-gen Mac-Mini it's not true
>> >>for *any* x86.
>> >>M1 is slower than top Zen3 bins and about the same or a little slower
>> >>than top Comet Lake.
>> >>Probably somewhat slower than top Tiger Lake, but that comparison is
>> >>rather close.
>> >>Probably, measurably slower than top Rocket Lake, but I didn't look at
>> >>Rocket Lake closely.
>> >
>> > I have a Mac Mini M1, and it seems fast--very fast for some workloads (hard to
>> > predict branches,
>> Yes, my assembler doesn't work as well as on x86 ;p
>> likes loop unrolling very much :p
>> Got 10% just coknverting suboutine in macro and calling several times :P
>> or working set in the 100-200KB range). It is not the
>> > fastest CPU on the planet, but it likely is the fastest laptop CPU.
>> Sorry can't gree. Blows away x86 alright.
>> At < 10W
>> > at the AC plug it compares pretty favorably to 60W CPUs. If you have a
>> > relatively short benchmark (say, one file, C or C++, can be run from the Unix
>> > command line, doesn't require me to install anything else, should run in less
>> > than 5 minutes), I can compile it and run it for you, and then you can compare
>> > those results to any system you like. I don't think comparing optimized AVX
>> > is going to be useful, but simple integer or floating point algorithms would
>> > be best.
>> It can compare with optimised AVX alright :P
>>
>
> Do you want to test it?
> I have a linear algebra core (Cholesky decomposition) coded in optimised AVX (Intel intrisinc) and the same algorithm in
> plain C++ that can be, in theory, vectorized by good compiler.

Of course, would be interresting how M1 does that.

>
> The most interesting would be compiling for Intel Mac and then running binary through Rosetta, as Kent did for my first test.
> I don't know if you can do it without Intel Mac.

Apples gcc support cross compilation. I build x86 binaries no problem. Only thing is if they contain AVX code won't work
as Rosetta does not supports AVX...
>
>
>
>> >
>> > Kent
>>
>>
>> --
>> something dumb

--
something dumb

On Thursday, July 8, 2021 at 4:48:16 PM UTC+3, Branimir Maksimovic wrote:
> On 2021-07-08, Michael S <already...@yahoo.com> wrote:
> > On Wednesday, July 7, 2021 at 12:43:00 AM UTC+3, Branimir Maksimovic wrote:
> >> On 2021-07-06, Kent Dickey <ke...@provalid.com> wrote:
> >> > In article <80ac50a0-dde2-4a66...@googlegroups.com>,
> >> > Michael S <already...@yahoo.com> wrote:
> >> >>On Tuesday, July 6, 2021 at 7:16:01 PM UTC+3, Branimir Maksimovic wrote:
> >> >>> On 2021-07-06, Michael S <already...@yahoo.com> wrote:
> >> >>> > I can believe that M1@3.2 GHz/Rosetta is able to run x64 software as
> >> >>fast as i3-8100B but have trouble believing that it could match i7-8700B
> >> >>either in single thread or in multithread throughput. Unless, of course,
> >> >>absolute majority of run time spent in native libraries.
> >> >>> You don't count that M1 is ~25-33% faster single core then any x86 :P
> >> >>
> >> >>I took it into account.
> >> >>
> >> >>Besides, while it's true for x86 CPUs in prev-gen Mac-Mini it's not true
> >> >>for *any* x86.
> >> >>M1 is slower than top Zen3 bins and about the same or a little slower
> >> >>than top Comet Lake.
> >> >>Probably somewhat slower than top Tiger Lake, but that comparison is
> >> >>rather close.
> >> >>Probably, measurably slower than top Rocket Lake, but I didn't look at
> >> >>Rocket Lake closely.
> >> >
> >> > I have a Mac Mini M1, and it seems fast--very fast for some workloads (hard to
> >> > predict branches,
> >> Yes, my assembler doesn't work as well as on x86 ;p
> >> likes loop unrolling very much :p
> >> Got 10% just coknverting suboutine in macro and calling several times :P
> >> or working set in the 100-200KB range). It is not the
> >> > fastest CPU on the planet, but it likely is the fastest laptop CPU.
> >> Sorry can't gree. Blows away x86 alright.
> >> At < 10W
> >> > at the AC plug it compares pretty favorably to 60W CPUs. If you have a
> >> > relatively short benchmark (say, one file, C or C++, can be run from the Unix
> >> > command line, doesn't require me to install anything else, should run in less
> >> > than 5 minutes), I can compile it and run it for you, and then you can compare
> >> > those results to any system you like. I don't think comparing optimized AVX
> >> > is going to be useful, but simple integer or floating point algorithms would
> >> > be best.
> >> It can compare with optimised AVX alright :P
> >>
> >
> > Do you want to test it?
> > I have a linear algebra core (Cholesky decomposition) coded in optimised AVX (Intel intrisinc) and the same algorithm in
> > plain C++ that can be, in theory, vectorized by good compiler.
> Of course, would be interresting how M1 does that.

It's in my public github repo already5chosen/others under directory cholesky_solver.
You can try it yourself, e.g. outer_product_c2x2hiv for intrinsic-based variant vs outer_product_c2x2hi
for the same algorithm in plain c++.
For speed measurement, I was mostly concerned with N=85.

Unfortunately, there is a big chance that without additional explanations you will not be able proceed.
The repo was intended for myself so didn't contain comprehensive readme.
Tomorrow, or much later today, I could answer few questions, but right now I have to work. :(

> >
> > The most interesting would be compiling for Intel Mac and then running binary through Rosetta, as Kent did for my first test.
> > I don't know if you can do it without Intel Mac.
> Apples gcc support cross compilation. I build x86 binaries no problem. Only thing is if they contain AVX code won't work
> as Rosetta does not supports AVX...

That a pity.
I heard about it a year ago, but completely forgot.

> >
> >
> >
> >> >
> >> > Kent
> >>
> >>
> >> --
> >> something dumb
>
>
> --
> something dumb