Branimir Maksimovic <branimir.maksimovic@gmail.com> writes:
>> 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

Yes, because it's only available in Apple products.

I admit to getting an iBook G4 in 2004, but at that time you could
install Linux on it. Mine never had MacOS installed.

But these days, Apple can afford not to get business from people like
me, or at least they think so.

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

On 2021-07-08, Michael S <already5chosen@yahoo.com> wrote:
> 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. :(

_stricmp not present on macOS, can't compile.

--
something dumb

On Thursday, July 8, 2021 at 6:28:46 PM UTC+3, Branimir Maksimovic wrote:
> On 2021-07-08, Michael S <already...@yahoo.com> wrote:
> > 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. :(
> _stricmp not present on macOS, can't compile.
>
>
> --
> something dumb

You can replace it with strcasecmp(). If it also does not work then strcmp().
In later case command line arguments will become case-sensitive.

In article <c5a7429b-b7e6-4fbc-ac98-bf5160c3a87dn@googlegroups.com>,
Michael S <already5chosen@yahoo.com> wrote:
>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;
>}
>
>static unsigned long long oneChildsInRange(int nDigits)
>{
> // initialize look-up tables
> tabs_t tabs;
> for (int i = 0; i < 19+10; ++i) {
> tabs.isChildTab[i] = i % nDigits == 0;
> tabs.x10remTab [i] = (i*10) % nDigits;
> }
>
> unsigned long long cnt = 0;
> for (int pref = 1; pref < 10; ++pref) {
> uint8_t prefixRem[1];
> prefixRem[0] = tabs.x10remTab[pref];
> cnt += countChildsRecursive(0, prefixRem, 1, &tabs);
> }
>
> return cnt;
>}
>
>//-- end
>
>Unlike the previous code, this variant on x86-64 is faster when compile
>with 'clang -march=native -O2'.
>gcc is significantly slower.

OK, on my Mac Mini M1 (all Apple compilers are clang):

---
m1-mini-bash$ cc -O2 -o michaels2 michaels2.c
m1-mini-bash$ time ./michaels2 13
13 1057516028

real 1m32.648s
user 1m32.311s
sys 0m0.098s
m1-mini-bash$ time ./michaels2 12
12 55121700430

real 7m30.212s
user 7m29.783s
sys 0m0.432s
---

And for comparison, my iMac Pro:

---
imacpro-bash$ cc -O2 -o michaels2 michaels2.c
imacpro-bash$ time michaels2 13
13 1057516028

real 1m50.732s
user 1m50.517s
sys 0m0.055s
imacpro-bash$ time michaels2 12
12 55121700430

real 9m45.505s
user 9m45.260s
sys 0m0.181s
---

Kent

On 2021-07-08, Michael S <already5chosen@yahoo.com> wrote:
> 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
bmaxa@Branimirs-Air cholesky_solver % g++-11 -O3 outer_product_c2x2hi/chol.cpp main.cpp -o chol -std=c++11
bmaxa@Branimirs-Air cholesky_solver % time ./chol 128
Layout='R'. N= 128. max. err: decomposition 5.116e-13, solver 9.845e-12. N= 128. 84.79 usec. 17.657 GMADD/s
../chol 128 1.48s user 0.02s system 85% cpu 1.752 total
bmaxa@Branimirs-Air cholesky_solver % g++ -O3 outer_product_c2x2hi/chol.cpp main.cpp -o chol -std=c++11
bmaxa@Branimirs-Air cholesky_solver % time ./chol 128
Layout='R'. N= 128. max. err: decomposition 5.116e-13, solver 1.001e-11. N= 128. 258.35 usec. 5.795 GMADD/s
../chol 128 4.16s user 0.02s system 95% cpu 4.358 total

gcc is much faster then Apples clang so it seems in this case...

--
something dumb

On 2021-07-08, Michael S <already5chosen@yahoo.com> wrote:
> On Thursday, July 8, 2021 at 6:28:46 PM UTC+3, Branimir Maksimovic wrote:
>> On 2021-07-08, Michael S <already...@yahoo.com> wrote:
>> > 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. :(
>> _stricmp not present on macOS, can't compile.
>>
>>
>> --
>> something dumb
>
> You can replace it with strcasecmp(). If it also does not work then strcmp().
> In later case command line arguments will become case-sensitive.
I have waited for you, that's one small change :P

--
something dumb

On 2021-07-08, Branimir Maksimovic <branimir.maksimovic@gmail.com> wrote:
> On 2021-07-08, Michael S <already5chosen@yahoo.com> wrote:
>> 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
> bmaxa@Branimirs-Air cholesky_solver % g++-11 -O3 outer_product_c2x2hi/chol.cpp main.cpp -o chol -std=c++11
> bmaxa@Branimirs-Air cholesky_solver % time ./chol 128
> Layout='R'. N= 128. max. err: decomposition 5.116e-13, solver 9.845e-12. N= 128. 84.79 usec. 17.657 GMADD/s
> ./chol 128 1.48s user 0.02s system 85% cpu 1.752 total
> bmaxa@Branimirs-Air cholesky_solver % g++ -O3 outer_product_c2x2hi/chol.cpp main.cpp -o chol -std=c++11
> bmaxa@Branimirs-Air cholesky_solver % time ./chol 128
> Layout='R'. N= 128. max. err: decomposition 5.116e-13, solver 1.001e-11. N= 128. 258.35 usec. 5.795 GMADD/s
> ./chol 128 4.16s user 0.02s system 95% cpu 4.358 total
>
> gcc is much faster then Apples clang so it seems in this case...
>
>
And through rosetta:
maxa@Branimirs-Air cholesky_solver % g++ -O3 outer_product_c2x2hi/chol.cpp main.cpp -o chol -std=c++11 -target x86_64-apple-darwin
bmaxa@Branimirs-Air cholesky_solver % time ./chol 128
Layout='R'. N= 128. max. err: decomposition 5.684e-13, solver 1.001e-11. N= 128. 274.58 usec. 5.452 GMADD/s
../chol 128 4.73s user 0.03s system 92% cpu 5.160 total
bmaxa@Branimirs-Air cholesky_solver % time ./chol 128
Layout='R'. N= 128. max. err: decomposition 5.684e-13, solver 1.001e-11. N= 128. 274.22 usec. 5.460 GMADD/s
../chol 128 4.74s user 0.03s system 99% cpu 4.801 total
gcc I don't have cross compiler...

--
something dumb

In article <teidncg9kKcBvnr9nZ2dnUU7-Y_NnZ2d@giganews.com>,
Kent Dickey <kegs@provalid.com> wrote:
>In article <c5a7429b-b7e6-4fbc-ac98-bf5160c3a87dn@googlegroups.com>,
>Michael S <already5chosen@yahoo.com> wrote:
>>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;
>>}
>>
>>static unsigned long long oneChildsInRange(int nDigits)
>>{
>> // initialize look-up tables
>> tabs_t tabs;
>> for (int i = 0; i < 19+10; ++i) {
>> tabs.isChildTab[i] = i % nDigits == 0;
>> tabs.x10remTab [i] = (i*10) % nDigits;
>> }
>>
>> unsigned long long cnt = 0;
>> for (int pref = 1; pref < 10; ++pref) {
>> uint8_t prefixRem[1];
>> prefixRem[0] = tabs.x10remTab[pref];
>> cnt += countChildsRecursive(0, prefixRem, 1, &tabs);
>> }
>>
>> return cnt;
>>}
>>
>>//-- end
>>
>>Unlike the previous code, this variant on x86-64 is faster when compile
>>with 'clang -march=native -O2'.
>>gcc is significantly slower.
>
>OK, on my Mac Mini M1 (all Apple compilers are clang):
>
>---
>m1-mini-bash$ cc -O2 -o michaels2 michaels2.c
>m1-mini-bash$ time ./michaels2 13
>13 1057516028
>
>real 1m32.648s
>user 1m32.311s
>sys 0m0.098s
>m1-mini-bash$ time ./michaels2 12
>12 55121700430
>
>real 7m30.212s
>user 7m29.783s
>sys 0m0.432s
>---

And I copied over the x86 executable (I do this since then I'm sure Apple can
in no way "cheat") and ran it:

--
m1-mini-bash$ time ./michaels2.x86 13
13 1057516028

real 1m26.825s
user 1m26.541s
sys 0m0.108s
m1-mini-bash$ time ./michaels2.x86 12
12 55121700430

real 8m5.908s
user 8m5.452s
sys 0m0.465s
--

Yes, that's right, for the argument "13", the JIT x86 code on Apple M1 ran
FASTER than the native compiled code. This did not happen for the "12"
version (which runs much longer).

>
>And for comparison, my iMac Pro:
>
>---
>imacpro-bash$ cc -O2 -o michaels2 michaels2.c
>imacpro-bash$ time michaels2 13
>13 1057516028
>
>real 1m50.732s
>user 1m50.517s
>sys 0m0.055s
>imacpro-bash$ time michaels2 12
>12 55121700430
>
>real 9m45.505s
>user 9m45.260s
>sys 0m0.181s
>---

Kent

On Thursday, July 8, 2021 at 7:36:04 PM UTC+3, Kent Dickey wrote:
> In article <teidncg9kKcBvnr9...@giganews.com>,
> Kent Dickey <ke...@provalid.com> wrote:
> >In article <c5a7429b-b7e6-4fbc...@googlegroups.com>,
> >Michael S <already...@yahoo.com> wrote:
> >>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;
> >>}
> >>
> >>static unsigned long long oneChildsInRange(int nDigits)
> >>{
> >> // initialize look-up tables
> >> tabs_t tabs;
> >> for (int i = 0; i < 19+10; ++i) {
> >> tabs.isChildTab[i] = i % nDigits == 0;
> >> tabs.x10remTab [i] = (i*10) % nDigits;
> >> }
> >>
> >> unsigned long long cnt = 0;
> >> for (int pref = 1; pref < 10; ++pref) {
> >> uint8_t prefixRem[1];
> >> prefixRem[0] = tabs.x10remTab[pref];
> >> cnt += countChildsRecursive(0, prefixRem, 1, &tabs);
> >> }
> >>
> >> return cnt;
> >>}
> >>
> >>//-- end
> >>
> >>Unlike the previous code, this variant on x86-64 is faster when compile
> >>with 'clang -march=native -O2'.
> >>gcc is significantly slower.
> >
> >OK, on my Mac Mini M1 (all Apple compilers are clang):
> >
> >---
> >m1-mini-bash$ cc -O2 -o michaels2 michaels2.c
> >m1-mini-bash$ time ./michaels2 13
> >13 1057516028
> >
> >real 1m32.648s
> >user 1m32.311s
> >sys 0m0.098s
> >m1-mini-bash$ time ./michaels2 12
> >12 55121700430
> >
> >real 7m30.212s
> >user 7m29.783s
> >sys 0m0.432s
> >---
> And I copied over the x86 executable (I do this since then I'm sure Apple can
> in no way "cheat") and ran it:
>
> --
> m1-mini-bash$ time ./michaels2.x86 13
> 13 1057516028
>
> real 1m26.825s
> user 1m26.541s
> sys 0m0.108s
> m1-mini-bash$ time ./michaels2.x86 12
> 12 55121700430
>
> real 8m5.908s
> user 8m5.452s
> sys 0m0.465s
> --
>
> Yes, that's right, for the argument "13", the JIT x86 code on Apple M1 ran
> FASTER than the native compiled code. This did not happen for the "12"
> version (which runs much longer).
> >
> >And for comparison, my iMac Pro:
> >
> >---
> >imacpro-bash$ cc -O2 -o michaels2 michaels2.c
> >imacpro-bash$ time michaels2 13
> >13 1057516028
> >
> >real 1m50.732s
> >user 1m50.517s
> >sys 0m0.055s
> >imacpro-bash$ time michaels2 12
> >12 55121700430
> >
> >real 9m45.505s
> >user 9m45.260s
> >sys 0m0.181s
> >---
>
> Kent

Diz JIT boy is a BAD mazafaka!

In article <2021Jul8.164728@mips.complang.tuwien.ac.at>,
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> Branimir Maksimovic <branimir.maksimovic@gmail.com> writes:
> >Worse is that I can't install Linux at this time
>
> Yes, because it's only available in Apple products.
>
> I admit to getting an iBook G4 in 2004, but at that time you could
> install Linux on it. Mine never had MacOS installed.

There is a crowdfunded Linux project underway for the M1, and it seems to
be making reasonable progress. While some of Apple's decisions have not
been especially helpful for the Linux work, they have not locked down the
bootloader, so there's no need for jailbreaking.

https://www.patreon.com/marcan

John

On 2021-07-08, Michael S <already5chosen@yahoo.com> wrote:
> On Thursday, July 8, 2021 at 7:36:04 PM UTC+3, Kent Dickey wrote:
>> In article <teidncg9kKcBvnr9...@giganews.com>,
>> Kent Dickey <ke...@provalid.com> wrote:
>> >In article <c5a7429b-b7e6-4fbc...@googlegroups.com>,
>> >Michael S <already...@yahoo.com> wrote:
>> >>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;
>> >>}
>> >>
>> >>static unsigned long long oneChildsInRange(int nDigits)
>> >>{
>> >> // initialize look-up tables
>> >> tabs_t tabs;
>> >> for (int i = 0; i < 19+10; ++i) {
>> >> tabs.isChildTab[i] = i % nDigits == 0;
>> >> tabs.x10remTab [i] = (i*10) % nDigits;
>> >> }
>> >>
>> >> unsigned long long cnt = 0;
>> >> for (int pref = 1; pref < 10; ++pref) {
>> >> uint8_t prefixRem[1];
>> >> prefixRem[0] = tabs.x10remTab[pref];
>> >> cnt += countChildsRecursive(0, prefixRem, 1, &tabs);
>> >> }
>> >>
>> >> return cnt;
>> >>}
>> >>
>> >>//-- end
>> >>
>> >>Unlike the previous code, this variant on x86-64 is faster when compile
>> >>with 'clang -march=native -O2'.
>> >>gcc is significantly slower.
>> >
>> >OK, on my Mac Mini M1 (all Apple compilers are clang):
>> >
>> >---
>> >m1-mini-bash$ cc -O2 -o michaels2 michaels2.c
>> >m1-mini-bash$ time ./michaels2 13
>> >13 1057516028
>> >
>> >real 1m32.648s
>> >user 1m32.311s
>> >sys 0m0.098s
>> >m1-mini-bash$ time ./michaels2 12
>> >12 55121700430
>> >
>> >real 7m30.212s
>> >user 7m29.783s
>> >sys 0m0.432s
>> >---
>> And I copied over the x86 executable (I do this since then I'm sure Apple can
>> in no way "cheat") and ran it:
>>
>> --
>> m1-mini-bash$ time ./michaels2.x86 13
>> 13 1057516028
>>
>> real 1m26.825s
>> user 1m26.541s
>> sys 0m0.108s
>> m1-mini-bash$ time ./michaels2.x86 12
>> 12 55121700430
>>
>> real 8m5.908s
>> user 8m5.452s
>> sys 0m0.465s
>> --
>>
>> Yes, that's right, for the argument "13", the JIT x86 code on Apple M1 ran
>> FASTER than the native compiled code. This did not happen for the "12"
>> version (which runs much longer).
>> >
>> >And for comparison, my iMac Pro:
>> >
>> >---
>> >imacpro-bash$ cc -O2 -o michaels2 michaels2.c
>> >imacpro-bash$ time michaels2 13
>> >13 1057516028
>> >
>> >real 1m50.732s
>> >user 1m50.517s
>> >sys 0m0.055s
>> >imacpro-bash$ time michaels2 12
>> >12 55121700430
>> >
>> >real 9m45.505s
>> >user 9m45.260s
>> >sys 0m0.181s
>> >---
>>
>> Kent
>
> Diz JIT boy is a BAD mazafaka!
>
It's not JIT it's M1, native code is faster then x86 :P
maxa@Branimirs-Air euler % gcc -O3 euler413i.c -o euler413i -target x86_64-apple-darwin
bmaxa@Branimirs-Air euler % time ./euler413i 13
13 1057516028
../euler413i 13 105.50s user 0.35s system 99% cpu 1:46.18 total
bmaxa@Branimirs-Air euler % time ./euler413i 12
12 55121700430
../euler413i 12 567.55s user 1.88s system 99% cpu 9:29.62 total
bmaxa@Branimirs-Air euler % gcc -O3 euler413i.c -o euler413i
bmaxa@Branimirs-Air euler % time ./euler413i 13
13 1057516028
../euler413i 13 93.72s user 0.31s system 99% cpu 1:34.76 total
bmaxa@Branimirs-Air euler % time ./euler413i 12
12 55121700430
../euler413i 12 458.93s user 1.39s system 99% cpu 7:40.35 total

--
something dumb

On 2021-07-08, John Dallman <jgd@cix.co.uk> wrote:
> In article <2021Jul8.164728@mips.complang.tuwien.ac.at>,
> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
>> Branimir Maksimovic <branimir.maksimovic@gmail.com> writes:
>> >Worse is that I can't install Linux at this time
>>
>> Yes, because it's only available in Apple products.
>>
>> I admit to getting an iBook G4 in 2004, but at that time you could
>> install Linux on it. Mine never had MacOS installed.
>
> There is a crowdfunded Linux project underway for the M1, and it seems to
> be making reasonable progress. While some of Apple's decisions have not
> been especially helpful for the Linux work, they have not locked down the
> bootloader, so there's no need for jailbreaking.
+1

--
something dumb

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

Yes, this raises some philosophical/political issues for me, but the
more real problems are technical: AFAIU you can't buy a machine with
such a CPU where the RAM and SSD can be later upgraded.
That's a kind of planned obsolescence that I find very problematic, also
from an environmental point of view.

Stefan

On Thursday, July 8, 2021 at 8:59:20 PM UTC+3, Branimir Maksimovic wrote:
> On 2021-07-08, Michael S <already...@yahoo.com> wrote:
> > On Thursday, July 8, 2021 at 7:36:04 PM UTC+3, Kent Dickey wrote:
> >> In article <teidncg9kKcBvnr9...@giganews.com>,
> >> Kent Dickey <ke...@provalid.com> wrote:
> >> >In article <c5a7429b-b7e6-4fbc...@googlegroups.com>,
> >> >Michael S <already...@yahoo.com> wrote:
> >> >>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;
> >> >>}
> >> >>
> >> >>static unsigned long long oneChildsInRange(int nDigits)
> >> >>{
> >> >> // initialize look-up tables
> >> >> tabs_t tabs;
> >> >> for (int i = 0; i < 19+10; ++i) {
> >> >> tabs.isChildTab[i] = i % nDigits == 0;
> >> >> tabs.x10remTab [i] = (i*10) % nDigits;
> >> >> }
> >> >>
> >> >> unsigned long long cnt = 0;
> >> >> for (int pref = 1; pref < 10; ++pref) {
> >> >> uint8_t prefixRem[1];
> >> >> prefixRem[0] = tabs.x10remTab[pref];
> >> >> cnt += countChildsRecursive(0, prefixRem, 1, &tabs);
> >> >> }
> >> >>
> >> >> return cnt;
> >> >>}
> >> >>
> >> >>//-- end
> >> >>
> >> >>Unlike the previous code, this variant on x86-64 is faster when compile
> >> >>with 'clang -march=native -O2'.
> >> >>gcc is significantly slower.
> >> >
> >> >OK, on my Mac Mini M1 (all Apple compilers are clang):
> >> >
> >> >---
> >> >m1-mini-bash$ cc -O2 -o michaels2 michaels2.c
> >> >m1-mini-bash$ time ./michaels2 13
> >> >13 1057516028
> >> >
> >> >real 1m32.648s
> >> >user 1m32.311s
> >> >sys 0m0.098s
> >> >m1-mini-bash$ time ./michaels2 12
> >> >12 55121700430
> >> >
> >> >real 7m30.212s
> >> >user 7m29.783s
> >> >sys 0m0.432s
> >> >---
> >> And I copied over the x86 executable (I do this since then I'm sure Apple can
> >> in no way "cheat") and ran it:
> >>
> >> --
> >> m1-mini-bash$ time ./michaels2.x86 13
> >> 13 1057516028
> >>
> >> real 1m26.825s
> >> user 1m26.541s
> >> sys 0m0.108s
> >> m1-mini-bash$ time ./michaels2.x86 12
> >> 12 55121700430
> >>
> >> real 8m5.908s
> >> user 8m5.452s
> >> sys 0m0.465s
> >> --
> >>
> >> Yes, that's right, for the argument "13", the JIT x86 code on Apple M1 ran
> >> FASTER than the native compiled code. This did not happen for the "12"
> >> version (which runs much longer).
> >> >
> >> >And for comparison, my iMac Pro:
> >> >
> >> >---
> >> >imacpro-bash$ cc -O2 -o michaels2 michaels2.c
> >> >imacpro-bash$ time michaels2 13
> >> >13 1057516028
> >> >
> >> >real 1m50.732s
> >> >user 1m50.517s
> >> >sys 0m0.055s
> >> >imacpro-bash$ time michaels2 12
> >> >12 55121700430
> >> >
> >> >real 9m45.505s
> >> >user 9m45.260s
> >> >sys 0m0.181s
> >> >---
> >>
> >> Kent
> >
> > Diz JIT boy is a BAD mazafaka!
> >
> It's not JIT it's M1, native code is faster then x86 :P
> maxa@Branimirs-Air euler % gcc -O3 euler413i.c -o euler413i -target x86_64-apple-darwin

In order to see the effect, observed by Kent, you should compile x86-64 binary with "clang -O2 -march=skylake".
As I said above, in this particular program clang-x64 is measurably faster than gcc-x64.
That's assuming that your gcc is a real gcc rather than alias to clang, as typical on MacOS.

> bmaxa@Branimirs-Air euler % time ./euler413i 13
> 13 1057516028
> ./euler413i 13 105.50s user 0.35s system 99% cpu 1:46.18 total
> bmaxa@Branimirs-Air euler % time ./euler413i 12
> 12 55121700430
> ./euler413i 12 567.55s user 1.88s system 99% cpu 9:29.62 total
> bmaxa@Branimirs-Air euler % gcc -O3 euler413i.c -o euler413i
> bmaxa@Branimirs-Air euler % time ./euler413i 13
> 13 1057516028
> ./euler413i 13 93.72s user 0.31s system 99% cpu 1:34.76 total
> bmaxa@Branimirs-Air euler % time ./euler413i 12
> 12 55121700430
> ./euler413i 12 458.93s user 1.39s system 99% cpu 7:40.35 total
>
>
> --
> something dumb

On 2021-07-08, Michael S <already5chosen@yahoo.com> wrote:
> On Thursday, July 8, 2021 at 8:59:20 PM UTC+3, Branimir Maksimovic wrote:
>> On 2021-07-08, Michael S <already...@yahoo.com> wrote:
>> > On Thursday, July 8, 2021 at 7:36:04 PM UTC+3, Kent Dickey wrote:
>> >> In article <teidncg9kKcBvnr9...@giganews.com>,
>> >> Kent Dickey <ke...@provalid.com> wrote:
>> >> >In article <c5a7429b-b7e6-4fbc...@googlegroups.com>,
>> >> >Michael S <already...@yahoo.com> wrote:
>> >> >>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;
>> >> >>}
>> >> >>
>> >> >>static unsigned long long oneChildsInRange(int nDigits)
>> >> >>{
>> >> >> // initialize look-up tables
>> >> >> tabs_t tabs;
>> >> >> for (int i = 0; i < 19+10; ++i) {
>> >> >> tabs.isChildTab[i] = i % nDigits == 0;
>> >> >> tabs.x10remTab [i] = (i*10) % nDigits;
>> >> >> }
>> >> >>
>> >> >> unsigned long long cnt = 0;
>> >> >> for (int pref = 1; pref < 10; ++pref) {
>> >> >> uint8_t prefixRem[1];
>> >> >> prefixRem[0] = tabs.x10remTab[pref];
>> >> >> cnt += countChildsRecursive(0, prefixRem, 1, &tabs);
>> >> >> }
>> >> >>
>> >> >> return cnt;
>> >> >>}
>> >> >>
>> >> >>//-- end
>> >> >>
>> >> >>Unlike the previous code, this variant on x86-64 is faster when compile
>> >> >>with 'clang -march=native -O2'.
>> >> >>gcc is significantly slower.
>> >> >
>> >> >OK, on my Mac Mini M1 (all Apple compilers are clang):
>> >> >
>> >> >---
>> >> >m1-mini-bash$ cc -O2 -o michaels2 michaels2.c
>> >> >m1-mini-bash$ time ./michaels2 13
>> >> >13 1057516028
>> >> >
>> >> >real 1m32.648s
>> >> >user 1m32.311s
>> >> >sys 0m0.098s
>> >> >m1-mini-bash$ time ./michaels2 12
>> >> >12 55121700430
>> >> >
>> >> >real 7m30.212s
>> >> >user 7m29.783s
>> >> >sys 0m0.432s
>> >> >---
>> >> And I copied over the x86 executable (I do this since then I'm sure Apple can
>> >> in no way "cheat") and ran it:
>> >>
>> >> --
>> >> m1-mini-bash$ time ./michaels2.x86 13
>> >> 13 1057516028
>> >>
>> >> real 1m26.825s
>> >> user 1m26.541s
>> >> sys 0m0.108s
>> >> m1-mini-bash$ time ./michaels2.x86 12
>> >> 12 55121700430
>> >>
>> >> real 8m5.908s
>> >> user 8m5.452s
>> >> sys 0m0.465s
>> >> --
>> >>
>> >> Yes, that's right, for the argument "13", the JIT x86 code on Apple M1 ran
>> >> FASTER than the native compiled code. This did not happen for the "12"
>> >> version (which runs much longer).
>> >> >
>> >> >And for comparison, my iMac Pro:
>> >> >
>> >> >---
>> >> >imacpro-bash$ cc -O2 -o michaels2 michaels2.c
>> >> >imacpro-bash$ time michaels2 13
>> >> >13 1057516028
>> >> >
>> >> >real 1m50.732s
>> >> >user 1m50.517s
>> >> >sys 0m0.055s
>> >> >imacpro-bash$ time michaels2 12
>> >> >12 55121700430
>> >> >
>> >> >real 9m45.505s
>> >> >user 9m45.260s
>> >> >sys 0m0.181s
>> >> >---
>> >>
>> >> Kent
>> >
>> > Diz JIT boy is a BAD mazafaka!
>> >
>> It's not JIT it's M1, native code is faster then x86 :P
>> maxa@Branimirs-Air euler % gcc -O3 euler413i.c -o euler413i -target x86_64-apple-darwin
>
> In order to see the effect, observed by Kent, you should compile x86-64 binary with "clang -O2 -march=skylake".
> As I said above, in this particular program clang-x64 is measurably faster than gcc-x64.
> That's assuming that your gcc is a real gcc rather than alias to clang, as typical on MacOS.

I have real gcc for ARM, gcc-11, that is, yes in this particular case it is slower,
but produces significantly faster code then Apples clang most of the time...
Yes gcc is alias for clang on macOS, so when I want real gcc I use gcc-11 command.
Here is result with your parameters to clang
maxa@Branimirs-Air euler % gcc -O2 euler413i.c -o euler413i -march=skylake -target x86_64-apple-darwin
bmaxa@Branimirs-Air euler % time ./euler413i 13
13 1057516028
../euler413i 13 96.14s user 0.44s system 99% cpu 1:36.94 total
bmaxa@Branimirs-Air euler % time ./euler413i 12
12 55121700430
../euler413i 12 487.02s user 2.13s system 99% cpu 8:09.21 total

On 7/6/2021 10:07 PM, Kent Dickey wrote:
> 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.
[...]

Thank you! I am interested in the output. I should have some more time
tonight to analyze the results. A lot of contention is in the debug
parameters. Also, I have not yet padded and aligned data structures to
cache lines. However, I should have some more time in a couple of days
to post a new version that should run a heck of a lot more efficiently.
My poor mans RCU algorihtm should be able to get some pretty decent
numbers without having to use kernel RCU. Its an analog in user space
that can be created in 100% pure C++.

One of my goals is to distribute it out so threads are not hammering the
same proxy collector.

The interesting part is going to be comparing the numbers you got vs the
new version.

Also, I am creating way to many threads. I need to trim that down to:

https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency

Also, the cache lines should be:

https://en.cppreference.com/w/cpp/thread/hardware_destructive_interference_size

On Thursday, July 8, 2021 at 7:14:13 PM UTC+3, Branimir Maksimovic wrote:
> On 2021-07-08, Michael S <already...@yahoo.com> wrote:
> > 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
> bmaxa@Branimirs-Air cholesky_solver % g++-11 -O3 outer_product_c2x2hi/chol.cpp main.cpp -o chol -std=c++11
> bmaxa@Branimirs-Air cholesky_solver % time ./chol 128
> Layout='R'. N= 128. max. err: decomposition 5.116e-13, solver 9.845e-12. N= 128. 84.79 usec. 17.657 GMADD/s

That's prety good, even if not as fast as optimized AVX2 on top x86.

> ./chol 128 1.48s user 0.02s system 85% cpu 1.752 total
> bmaxa@Branimirs-Air cholesky_solver % g++ -O3 outer_product_c2x2hi/chol.cpp main.cpp -o chol -std=c++11
> bmaxa@Branimirs-Air cholesky_solver % time ./chol 128
> Layout='R'. N= 128. max. err: decomposition 5.116e-13, solver 1.001e-11. N= 128. 258.35 usec. 5.795 GMADD/s
> ./chol 128 4.16s user 0.02s system 95% cpu 4.358 total

That's no good. But clang on x86 is equally bad.

>
> gcc is much faster then Apples clang so it seems in this case...
>
>
> --
> something dumb

Now you can compile and run outer_product_c2x2hiv on you Zen2 and compare M1 with optimized AVX2 coded in intrinsic functions (which is still not as fast as real asm, which is another 10-15% faster, but I only have asm for Windows, so you can't test) on CPU that is ~30% slower than the fastest x86 out here. I expect 19-20 GMADD/s for N=128. My Xeon-E gets 20.5.
Just don't forget to specify -march=skylake in gcc command line.

BTW, I am not that interested in N=128. For me an important data size is N=83.
As far as goodness of the CPU goes, getting high GMADD/s for smaller values of N is more challenging. Also, I consider it more important,
not just for me, but for majority of people that run Linear Algebra on general-purpose CPUs. That's because for bigger Ns CPUs are
not competitive with GPUs anyway, but for N under 100, CPU is often the fastest available engine.
I suspect that with smaller N M1 will do relatively better.

On 7/6/2021 5:07 PM, Branimir Maksimovic wrote:
> 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
>
>

Thank you! I will have another version that should get better numbers,
run faster. No debug, and aligned and padded structures. Also, it just
might be distributed.

On 2021-07-08, Michael S <already5chosen@yahoo.com> wrote:
> On Thursday, July 8, 2021 at 7:14:13 PM UTC+3, Branimir Maksimovic wrote:
>> On 2021-07-08, Michael S <already...@yahoo.com> wrote:
>> > 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
>> bmaxa@Branimirs-Air cholesky_solver % g++-11 -O3 outer_product_c2x2hi/chol.cpp main.cpp -o chol -std=c++11
>> bmaxa@Branimirs-Air cholesky_solver % time ./chol 128
>> Layout='R'. N= 128. max. err: decomposition 5.116e-13, solver 9.845e-12. N= 128. 84.79 usec. 17.657 GMADD/s
>
> That's prety good, even if not as fast as optimized AVX2 on top x86.
>
>> ./chol 128 1.48s user 0.02s system 85% cpu 1.752 total
>> bmaxa@Branimirs-Air cholesky_solver % g++ -O3 outer_product_c2x2hi/chol.cpp main.cpp -o chol -std=c++11
>> bmaxa@Branimirs-Air cholesky_solver % time ./chol 128
>> Layout='R'. N= 128. max. err: decomposition 5.116e-13, solver 1.001e-11. N= 128. 258.35 usec. 5.795 GMADD/s
>> ./chol 128 4.16s user 0.02s system 95% cpu 4.358 total
>
> That's no good. But clang on x86 is equally bad.
>
>>
>> gcc is much faster then Apples clang so it seems in this case...
>>
>>
>> --
>> something dumb
>
> Now you can compile and run outer_product_c2x2hiv on you Zen2 and compare M1 with optimized AVX2 coded in intrinsic functions (which is still not as fast as real asm, which is another 10-15% faster, but I only have asm for Windows, so you can't test) on CPU that is ~30% slower than the fastest x86 out here. I expect 19-20 GMADD/s for N=128. My Xeon-E gets 20.5.
> Just don't forget to specify -march=skylake in gcc command line.
>
> BTW, I am not that interested in N=128. For me an important data size is N=83.
> As far as goodness of the CPU goes, getting high GMADD/s for smaller values of N is more challenging. Also, I consider it more important,
> not just for me, but for majority of people that run Linear Algebra on general-purpose CPUs. That's because for bigger Ns CPUs are
> not competitive with GPUs anyway, but for N under 100, CPU is often the fastest available engine.
> I suspect that with smaller N M1 will do relatively better.
>
>
On Air with heavy load ~2500Mhz
maxa@Branimirs-Air cholesky_solver % time ./chol 83
Layout='R'. N= 83. max. err: decomposition 3.126e-13, solver 1.484e-11. N= 83. 108.82 usec. 3.887 GMADD/s
../chol 83 4.20s user 0.01s system 93% cpu 4.503 total

On 2700X with heavy load ~2200Mhz
/.../cholesky_solver/outer_product_c2x2hiv >>> time ./chol 83 ±[●●][master]
Layout='R'. N= 83. max. err: decomposition 3.126e-13, solver 1.370e-11. N= 83. 80.11 usec. 5.280 GMADD/s
../chol 83 3.36s user 0.02s system 99% cpu 3.407 total

So 2700X is better in this case, but wait, let's try clang
~/.../cholesky_solver/outer_product_c2x2hiv >>> time ./chol 83 ±[●●][master]
Layout='R'. N= 83. max. err: decomposition 3.126e-13, solver 1.523e-11. N= 83. 78.16 usec. 5.412 GMADD/s
../chol 83 4.32s user 0.03s system 99% cpu 4.385 total

So clang is slower for both x86 and M1 in this case, but x86 is 8 threads busy with WCG
and M1 is just two threads busy with WCG :P

--
something dumb

On Friday, July 9, 2021 at 2:56:04 AM UTC+3, Branimir Maksimovic wrote:
> On 2021-07-08, Michael S <already...@yahoo.com> wrote:
> > On Thursday, July 8, 2021 at 7:14:13 PM UTC+3, Branimir Maksimovic wrote:
> >> On 2021-07-08, Michael S <already...@yahoo.com> wrote:
> >> > 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
> >> bmaxa@Branimirs-Air cholesky_solver % g++-11 -O3 outer_product_c2x2hi/chol.cpp main.cpp -o chol -std=c++11
> >> bmaxa@Branimirs-Air cholesky_solver % time ./chol 128
> >> Layout='R'. N= 128. max. err: decomposition 5.116e-13, solver 9.845e-12. N= 128. 84.79 usec. 17.657 GMADD/s
> >
> > That's prety good, even if not as fast as optimized AVX2 on top x86.
> >
> >> ./chol 128 1.48s user 0.02s system 85% cpu 1.752 total
> >> bmaxa@Branimirs-Air cholesky_solver % g++ -O3 outer_product_c2x2hi/chol.cpp main.cpp -o chol -std=c++11
> >> bmaxa@Branimirs-Air cholesky_solver % time ./chol 128
> >> Layout='R'. N= 128. max. err: decomposition 5.116e-13, solver 1.001e-11. N= 128. 258.35 usec. 5.795 GMADD/s
> >> ./chol 128 4.16s user 0.02s system 95% cpu 4.358 total
> >
> > That's no good. But clang on x86 is equally bad.
> >
> >>
> >> gcc is much faster then Apples clang so it seems in this case...
> >>
> >>
> >> --
> >> something dumb
> >
> > Now you can compile and run outer_product_c2x2hiv on you Zen2 and compare M1 with optimized AVX2 coded in intrinsic functions (which is still not as fast as real asm, which is another 10-15% faster, but I only have asm for Windows, so you can't test) on CPU that is ~30% slower than the fastest x86 out here. I expect 19-20 GMADD/s for N=128. My Xeon-E gets 20.5.
> > Just don't forget to specify -march=skylake in gcc command line.
> >
> > BTW, I am not that interested in N=128. For me an important data size is N=83.
> > As far as goodness of the CPU goes, getting high GMADD/s for smaller values of N is more challenging. Also, I consider it more important,
> > not just for me, but for majority of people that run Linear Algebra on general-purpose CPUs. That's because for bigger Ns CPUs are
> > not competitive with GPUs anyway, but for N under 100, CPU is often the fastest available engine.
> > I suspect that with smaller N M1 will do relatively better.
> >
> >
> On Air with heavy load ~2500Mhz
> maxa@Branimirs-Air cholesky_solver % time ./chol 83
> Layout='R'. N= 83. max. err: decomposition 3.126e-13, solver 1.484e-11. N= 83. 108.82 usec. 3.887 GMADD/s
> ./chol 83 4.20s user 0.01s system 93% cpu 4.503 total
>
> On 2700X with heavy load ~2200Mhz
> /.../cholesky_solver/outer_product_c2x2hiv >>> time ./chol 83 ±[●●][master]
> Layout='R'. N= 83. max. err: decomposition 3.126e-13, solver 1.370e-11. N= 83. 80.11 usec. 5.280 GMADD/s
> ./chol 83 3.36s user 0.02s system 99% cpu 3.407 total
>
> So 2700X is better in this case, but wait, let's try clang
> ~/.../cholesky_solver/outer_product_c2x2hiv >>> time ./chol 83 ±[●●][master]
> Layout='R'. N= 83. max. err: decomposition 3.126e-13, solver 1.523e-11. N= 83. 78.16 usec. 5.412 GMADD/s
> ./chol 83 4.32s user 0.03s system 99% cpu 4.385 total
>
> So clang is slower for both x86 and M1 in this case, but x86 is 8 threads busy with WCG
> and M1 is just two threads busy with WCG :P
>

On 2021-07-08, Stefan Monnier wrote:
>> The M1 is pretty good. Too bad it's only available in Apple products.
>
> Yes, this raises some philosophical/political issues for me, but the
> more real problems are technical: AFAIU you can't buy a machine with
> such a CPU where the RAM and SSD can be later upgraded.
> That's a kind of planned obsolescence that I find very problematic, also
> from an environmental point of view.
>

I agree, but OTOH it's the clear trend in the industry. E.g. try
upgrading the RAM or storage of a smartphone, or even replacing the
battery. SoC and tighter integration seems to be the way to go.

I believe that there's actually a technical reason for the locked RAM
size - by putting the DRAM so close to the CPU silicon they can probably
get better memory performance (but it could also just be a cost thing,
I don't know).

/Marcus

jgd@cix.co.uk (John Dallman) writes:
>In article <2021Jul8.164728@mips.complang.tuwien.ac.at>,
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
>> Branimir Maksimovic <branimir.maksimovic@gmail.com> writes:
>> >Worse is that I can't install Linux at this time
>>
>> Yes, because it's only available in Apple products.
>>
>> I admit to getting an iBook G4 in 2004, but at that time you could
>> install Linux on it. Mine never had MacOS installed.
>
>There is a crowdfunded Linux project underway for the M1, and it seems to
>be making reasonable progress. While some of Apple's decisions have not
>been especially helpful for the Linux work, they have not locked down the
>bootloader, so there's no need for jailbreaking.
>
>https://www.patreon.com/marcan

If Apple really wanted to sell hardware, they would support such an
effort. If they don't, I go along with their wishes and won't buy
their stuff. Efforts without manufacturer support tend to be less and
less effective as hardware becomes more complicated. E.g., look at
the Nouveau driver for Nvidia graphics cards.

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

Branimir Maksimovic <branimir.maksimovic@gmail.com> wrote:
> 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:
>
> >
> > 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...

Gcc supported cross compilation for ages. The problem is/was with
assembler and linker. About 15 years ago I looked at this. At
that time Apple used hacked GNU assembler and they published sources.
But surces depended and Apple header files I know of nobody how
succeded compiling them without a Mac. There were substantial
chages in Apple toolchain but did the essential part change?
More precisy, can you get assembler and linker targeting Mac
on other platforms?

--
Waldek Hebisch

On 2021-07-10, antispam@math.uni.wroc.pl <antispam@math.uni.wroc.pl> wrote:
> Branimir Maksimovic <branimir.maksimovic@gmail.com> wrote:
>> 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:
>>
>> >
>> > 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...
>
> Gcc supported cross compilation for ages. The problem is/was with
> assembler and linker. About 15 years ago I looked at this. At
> that time Apple used hacked GNU assembler and they published sources.
They have it alright, I use it program M1 :P
Only choice for M1 right now :P
Copped with fasmg, but is seems does not produce valid binaries yet.
And I am not keen to code that myself :P
So gnu as it is :P

> But surces depended and Apple header files I know of nobody how
> succeded compiling them without a Mac. There were substantial
> chages in Apple toolchain but did the essential part change?
> More precisy, can you get assembler and linker targeting Mac
> on other platforms?

fasmg alright (for x86).

>

--
bmaxa now listens Last Rockers by Vice Squad from Punk and Disorderly Volume 1