Let's see if the dumb fucks can crack this one.

Matrix multiplication (matmult) is a very important task in computer science,
but it is also very computationally intensive. The basic routine for matmult
has a runtime of O(n^3) for an nxn matrix.

The following C program multiplies two matrices with n=512 using two different
methods. Both methods, however, are O(n^3), i.e. they perform the exact same
number of calculations.

But note the result:

../matmult

Run Time Mult 1: 0.0200255 seconds

Run Time Mult 2: 0.722272 seconds

Holy godzilla mutherfuckers! The first method is faster by 3700%!

Let's bite the bullet and go for a matrix of n=2048.

Result:

Run Time Mult 1: 1.9467 seconds

Run Time Mult 2: 100.011 seconds

Holy shiite! Now we have the first being faster by 5100%!

Let's have the dumb fuck code monkeys explain the differences.

IOW, lets have the code monkeys screech and bang the bars.

Ahahahahahahahahahahahahahahahahahahaha!

===============================
Begin C Program
===============================

#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <time.h>

int main()
{

int i, j, k, r, N=2048;

int *A = (int*)malloc(N * N * sizeof(int));
int *B = (int*)malloc(N * N * sizeof(int));
int *C = (int*)malloc(N * N * sizeof(int));

// vars for timing
double seconds;
struct timespec start, end;

// initialize matrices with random ints
for (i=0; i < N; i++) {
for (j=0; j < N; j++) {
A[i*N + j] = rand() % N;
B[i*N + j] = rand() % N;
}
}

/******** Matrix Multiply 1 **********/

// set start time
clock_gettime(CLOCK_THREAD_CPUTIME_ID, &start);

for (i=0; i < N; i++) {
for (k=0; k < N; k++) {
r = A[i*N+k];
for (j=0; j < N; j++) {
C[i*N+j] += B[k*N+j] * r;
}
}
}

// get and print end time
clock_gettime(CLOCK_THREAD_CPUTIME_ID, &end);
seconds = (double)((end.tv_sec-start.tv_sec)+(end.tv_nsec-start.tv_nsec)/1e9);
printf("\nRun Time Mult 1: %g seconds\n", seconds);

/******** Matrix Multiply 2 **********/

// set start time
clock_gettime(CLOCK_THREAD_CPUTIME_ID, &start);

for (j=0; j < N; j++) {
for (k=0; k < N; k++) {
r = B[k*N+j];
for (i=0; i < N; i++) {
C[i*N+j] += A[i*N+k] * r;
}
}
}
// get and print end time
clock_gettime(CLOCK_THREAD_CPUTIME_ID, &end);
seconds = (double)((end.tv_sec-start.tv_sec)+(end.tv_nsec-start.tv_nsec)/1e9);
printf("\nRun Time Mult 2: %g seconds\n", seconds);

}

===============================
End C Program
===============================

On Sat, 17 Feb 2024 15:21:59 +0000, Lester Thorpe wrote:

> Let's have the dumb fuck code monkeys explain the differences.

Funny, after I corrected the way you fucked up the indices I get
equivalent times. You really should use numpy if you don't know what
you're doing.

On 2/17/2024 10:21 AM, Lester Thorpe wrote:
> Let's see if the dumb fucks can crack this one.
>
> Matrix multiplication (matmult) is a very important task in computer science,
> but it is also very computationally intensive. The basic routine for matmult
> has a runtime of O(n^3) for an nxn matrix.
>
> The following C program multiplies two matrices with n=512 using two different
> methods. Both methods, however, are O(n^3), i.e. they perform the exact same
> number of calculations.
>
> But note the result:
>
> ./matmult
>
> Run Time Mult 1: 0.0200255 seconds
>
> Run Time Mult 2: 0.722272 seconds
>
> Holy godzilla mutherfuckers! The first method is faster by 3700%!
>
> Let's bite the bullet and go for a matrix of n=2048.
>
> Result:
>
> Run Time Mult 1: 1.9467 seconds
>
> Run Time Mult 2: 100.011 seconds
>
> Holy shiite! Now we have the first being faster by 5100%!

Running your original crap-code on my WSL install:

N = 1024:
Run Time Mult 1: 2.80069 seconds
Run Time Mult 2: 5.08096 seconds

N = 2048:
Run Time Mult 1: 22.5953 seconds
Run Time Mult 2: 51.7866 seconds

> Let's have the dumb fuck code monkeys explain the differences.
>
> IOW, lets have the code monkeys screech and bang the bars.
>
> Ahahahahahahahahahahahahahahahahahahaha!

Your screwed up calculations in lines 3 and 5 of Matrix Multiply 2, in
which the order of the indices aren't consistent with the order used in
Matrix Multiply 1.

Correcting them makes the run times identical.

What a waste of time, you cringey fucknugget.

Well, at least YOU can learn from my programming below.

> ===============================
> Begin C Program
> ===============================

<snip subhuman code from the "C Programmer Extraordinaire">

Here's how a "REAL PROGRAMMER" does it. This will run for N = 2^1
through 2^11 (2048)
=============================================================================================
#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <time.h>
#include <math.h>
void fillmatrices(int *A, int *B, int N) {
for (int i=0; i < N; i++) {
for (int j=0; j < N; j++) {
A[i*N + j] = rand() % N;
B[i*N + j] = rand() % N;
}
}
} void matrixmultiply_1(int *A, int *B, int *C, int N) {
for (int i=0; i < N; i++) {
for (int k=0; k < N; k++) {
int r = A[i*N+k];
for (int j=0; j < N; j++) {
C[i*N+j] += B[k*N+j] * r;
}
}
}
} void matrixmultiply_2(int *A, int *B, int *C, int N) {
for (int j=0; j < N; j++) {
for (int k=0; k < N; k++) {
int r = B[j*N+k];
for (int i=0; i < N; i++) {
C[j*N+i] += A[k*N+i] * r;
}
}
}
} double elapsedtime(clock_t start) {
return (clock() - (double)start)/CLOCKS_PER_SEC;
} int main(void) {
clock_t start;
srand(time(NULL));
for (int i = 1; i < 12; i++) {
int N = pow(2,i);
int arrsize = N * N * sizeof(int);
int *A = (int*)malloc(arrsize);
int *B = (int*)malloc(arrsize);
int *C = (int*)malloc(arrsize);
fillmatrices(A,B,N);
start = clock();
matrixmultiply_1(A,B,C,N);
printf("\nN = %d\n",N);
printf("Multiply 1 = %.6fs\n",elapsedtime(start));
start = clock();
matrixmultiply_2(A,B,C,N);
printf("Multiply 2 = %.6fs\n",elapsedtime(start));
free(A);
free(B);
free(C);
}
return(0);
} =============================================================================================

dfs@Win11-EE:~$ ./matmult

N = 2
Multiply 1 = 0.000030s
Multiply 2 = 0.000000s

N = 4
Multiply 1 = 0.000001s
Multiply 2 = 0.000001s

N = 8
Multiply 1 = 0.000002s
Multiply 2 = 0.000002s

N = 16
Multiply 1 = 0.000027s
Multiply 2 = 0.000011s

N = 32
Multiply 1 = 0.000121s
Multiply 2 = 0.000117s

N = 64
Multiply 1 = 0.000828s
Multiply 2 = 0.000785s

N = 128
Multiply 1 = 0.005100s
Multiply 2 = 0.005252s

N = 256
Multiply 1 = 0.040918s
Multiply 2 = 0.040801s

N = 512
Multiply 1 = 0.329828s
Multiply 2 = 0.329401s

N = 1024
Multiply 1 = 2.630907s
Multiply 2 = 2.628345s

N = 2048
Multiply 1 = 21.128377s
Multiply 2 = 21.150265s

(using corrected multiply2 code)

Note: srand(time(NULL)) isn't strictly necessary, but if you don't use
it each time you run the program you'll get arrays filled with the same
values for each N from the last run.

On 17 Feb 2024 17:42:54 GMT, rbowman wrote:

>
>> Let's have the dumb fuck code monkeys explain the differences.
>
> Funny, after I corrected the way you fucked up the indices I get
> equivalent times. You really should use numpy if you don't know what
> you're doing.
>

I did not ask for a code "correction."

I asked to explain the difference between the two timings.

You did not do that. You FAILED.

Monkey get no banana.

On Sat, 17 Feb 2024 15:45:43 -0500, DFS wrote:

>
> Correcting them makes the run times identical.
>

I did not ask for a code correction.

I asked for an explanation for the time differences.

You did not provide the answer. You FAILED.

Monkey get no banana.

L Thorpe <lt666@sixsixsix.net> wrote:
>On 17 Feb 2024 17:42:54 GMT, rbowman wrote:
>
>>> Let's have the dumb fuck code monkeys explain the differences.
>>
>> Funny, after I corrected the way you fucked up the indices I get
>> equivalent times. You really should use numpy if you don't know what
>> you're doing.
>
>I did not ask for a code "correction."
>
>I asked to explain the difference between the two timings.
>
>You did not do that. You FAILED.
>
>Monkey get no banana.

Who do you think you're fooling, with your geeked out bullshit,
Russell? You're just an OCD case beyond imagination. Probably strung
out on crystal meth, I mean I can't conceive of what else would make
you behave as you do, and be such an utter loudmouth about your
preoccupation with running Linux without the distro overhead. Mint
Cinnamon runs like a dream on my box, just as Win11 did, and Win12
would've. What am I missing? What can't I do with it? Just
bullshit.

--
Joel W. Crump

Amendment XIV
Section 1.

[...] No state shall make or enforce any law which shall
abridge the privileges or immunities of citizens of the
United States; nor shall any state deprive any person of
life, liberty, or property, without due process of law;
nor deny to any person within its jurisdiction the equal
protection of the laws.

Dobbs rewrites this, it is invalid precedent. States are
liable for denying needed abortions, e.g. TX.

On Sat, 17 Feb 2024 21:22:38 +0000, L Thorpe wrote:

> On 17 Feb 2024 17:42:54 GMT, rbowman wrote:
>
>
>>> Let's have the dumb fuck code monkeys explain the differences.
>>
>> Funny, after I corrected the way you fucked up the indices I get
>> equivalent times. You really should use numpy if you don't know what
>> you're doing.
>>
>>
> I did not ask for a code "correction."
>
> I asked to explain the difference between the two timings.
>
> You did not do that. You FAILED.
>
> Monkey get no banana.

The code correction is the difference between the two timings you ignorant
fuck. You fucked up the indices.

On Feb 17, 2024 at 10:21:59 AM EST, "Lester Thorpe" <lt@gnu.rocks> wrote:

Drivel snipped. You are utterly clueless.

On 2/17/2024 2:45 PM, DFS wrote:
> On 2/17/2024 10:21 AM, Lester Thorpe wrote:
>> Let's see if the dumb fucks can crack this one.
>>
>> Matrix multiplication (matmult) is a very important task in computer
>> science,
>> but it is also very computationally intensive.  The basic routine for
>> matmult
>> has a runtime of O(n^3) for an nxn matrix.
>>
>> The following C program multiplies two matrices with n=512 using two
>> different
>> methods.  Both methods, however, are O(n^3), i.e. they perform the
>> exact same
>> number of calculations.
>>
>> But note the result:
>>
>> ./matmult
>>
>> Run Time Mult 1: 0.0200255 seconds
>>
>> Run Time Mult 2: 0.722272 seconds
>>
>> Holy godzilla mutherfuckers!  The first method is faster by 3700%!
>>
>> Let's bite the bullet and go for a matrix of n=2048.
>>
>> Result:
>>
>> Run Time Mult 1: 1.9467 seconds
>>
>> Run Time Mult 2: 100.011 seconds
>>
>> Holy shiite!  Now we have the first being faster by 5100%!
>
>
> Running your original crap-code on my WSL install:
>
> N = 1024:
> Run Time Mult 1: 2.80069 seconds
> Run Time Mult 2: 5.08096 seconds
>
> N = 2048:
> Run Time Mult 1: 22.5953 seconds
> Run Time Mult 2: 51.7866 seconds
>
>
>> Let's have the dumb fuck code monkeys explain the differences.
>>
>> IOW, lets have the code monkeys screech and bang the bars.
>>
>> Ahahahahahahahahahahahahahahahahahahaha!
>
>
> Your screwed up calculations in lines 3 and 5 of Matrix Multiply 2, in
> which the order of the indices aren't consistent with the order used in
> Matrix Multiply 1.
>
> Correcting them makes the run times identical.
>
> What a waste of time, you cringey fucknugget.
>
> Well, at least YOU can learn from my programming below.
>
>
>
>> ===============================
>> Begin C Program
>> ===============================
>
> <snip subhuman code from the "C Programmer Extraordinaire">
>
>
> Here's how a "REAL PROGRAMMER" does it.  This will run for N = 2^1
> through 2^11 (2048)
> =============================================================================================
> #define _GNU_SOURCE
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
> #include <time.h>
> #include <math.h>
> void fillmatrices(int *A, int *B, int N) {
>   for (int i=0; i < N; i++) {
>     for (int j=0; j < N; j++) {
>       A[i*N + j] = rand() % N;
>        B[i*N + j] = rand() % N;
>     }
>   }
> }
> void matrixmultiply_1(int *A, int *B, int *C, int N) {
>   for (int i=0; i < N; i++) {
>      for (int k=0; k < N; k++) {
>        int r = A[i*N+k];
>        for (int j=0; j < N; j++) {
>          C[i*N+j] += B[k*N+j] * r;
>        }
>      }
>   }
> }
> void matrixmultiply_2(int *A, int *B, int *C, int N) {
>   for (int j=0; j < N; j++) {
>      for (int k=0; k < N; k++) {
>        int r = B[j*N+k];
>        for (int i=0; i < N; i++) {
>         C[j*N+i] += A[k*N+i] * r;
>        }
>      }
>   }
> }
> double elapsedtime(clock_t start) {
>     return (clock() - (double)start)/CLOCKS_PER_SEC;
> }
> int main(void) {
>     clock_t start;
>     srand(time(NULL));
>     for (int i = 1; i < 12; i++) {
>         int N = pow(2,i);
>         int arrsize = N * N * sizeof(int);
>         int *A = (int*)malloc(arrsize);
>         int *B = (int*)malloc(arrsize);
>         int *C = (int*)malloc(arrsize);
>         fillmatrices(A,B,N);
>         start = clock();
>         matrixmultiply_1(A,B,C,N);
>         printf("\nN = %d\n",N);
>         printf("Multiply 1 = %.6fs\n",elapsedtime(start));
>         start = clock();
>         matrixmultiply_2(A,B,C,N);
>         printf("Multiply 2 = %.6fs\n",elapsedtime(start));
>         free(A);
>         free(B);
>         free(C);
>     }
>   return(0);
> }
> =============================================================================================
>
> dfs@Win11-EE:~$ ./matmult
>
> N = 2
> Multiply 1 = 0.000030s
> Multiply 2 = 0.000000s
>
> N = 4
> Multiply 1 = 0.000001s
> Multiply 2 = 0.000001s
>
> N = 8
> Multiply 1 = 0.000002s
> Multiply 2 = 0.000002s
>
> N = 16
> Multiply 1 = 0.000027s
> Multiply 2 = 0.000011s
>
> N = 32
> Multiply 1 = 0.000121s
> Multiply 2 = 0.000117s
>
> N = 64
> Multiply 1 = 0.000828s
> Multiply 2 = 0.000785s
>
> N = 128
> Multiply 1 = 0.005100s
> Multiply 2 = 0.005252s
>
> N = 256
> Multiply 1 = 0.040918s
> Multiply 2 = 0.040801s
>
> N = 512
> Multiply 1 = 0.329828s
> Multiply 2 = 0.329401s
>
> N = 1024
> Multiply 1 = 2.630907s
> Multiply 2 = 2.628345s
>
> N = 2048
> Multiply 1 = 21.128377s
> Multiply 2 = 21.150265s
>
> (using corrected multiply2 code)
>
> Note: srand(time(NULL)) isn't strictly necessary, but if you don't use
> it each time you run the program you'll get arrays filled with the same
> values for each N from the last run.

You're all using someone else's code. Why don't you guys think for
yourselves and manipulate matrices in a readable way if you want others
to comment on that.

Why would you use A[i + j] to refer to a matrix instead of the readable
A[i][j] ?

Did somebody tell you to look inside the computer and use the way that
computer stores matricies? Did somebody tell you to make it your
business something that's not your business as far as this problem is
concerned?

Use A[i][j] for your matrix and rewrite the programs the way _you_ know
how matrix multiplication is done. Then your code becomes readable for
others, and they can comment on them.

--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

On 2/17/2024 9:21 AM, Lester Thorpe wrote:
> A[i*N + j] = rand() % N;

Why aren't you using a two-dimensional array A[i][j] to represent a matrix?

--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

On Sat, 17 Feb 2024 15:21:59 +0000, Lester Thorpe wrote:

> Let's see if the dumb fucks can crack this one.
>

As predicted, none of the dumb fuck code monkeys explained
the issue regarding my PERFECT C code.

Ha, ha, ha! One dumb fuck actually had the audacity to claim
that I messed up the indices. What a stupid cluck! Ha, ha!

Nope. There ain't nothing amiss with my PERFECT C code.

The problem is CACHE HITS/MISSES.

The CPU operates only on cache. RAM is essentially just another
disk drive. Data and instructions from RAM memory are loaded
into the cache and the CPU processes that cached data.

In the first matmult method, the data is accessed sequentially
so that there are minimal cache misses.

In the second matmult method, the data access jumps around
the array and this increases the cache misses which severely
slows performance.

Now for another shocker.

The program is compiled generically:

gcc -O2 -march=x86-64 -o matmult2 matmult.c

Result:

Run Time Mult 1: 2.72307 seconds

Run Time Mult 2: 121.731 seconds

The program is compiled to fit the CPU cache:

gcc -O2 -march=native -o matmult2 matmult.c

Run Time Mult 1: 1.9467 seconds

Run Time Mult 2: 100.011 seconds

Holy moley! There is roughly a 35% speed improvement
in the optimized code versus the generic code.

Distro jockeys take serious note. Your distro code
is junk.

Le 17-02-2024, L Thorpe <lt666@sixsixsix.net> a écrit :
> On Sat, 17 Feb 2024 15:45:43 -0500, DFS wrote:
>
>>
>> Correcting them makes the run times identical.
>>
>
> I did not ask for a code correction.

In fact, you did.

> I asked for an explanation for the time differences.

The explanation is the correction.

> You did not provide the answer.

He did. And rbowman did it, too.

> You FAILED.

You failed to understand two explanations. But you didn't failed to make
me laugh.

--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

Le 18-02-2024, Physfitfreak <Physfitfreak@gmail.com> a écrit :
>
> Why would you use A[i + j] to refer to a matrix instead of the readable
> A[i][j] ?

This one is really fun. I habitually don't read someone unable to remove
the useless part of the previous messages, but this one is really worth
it. I understand why you consider LP/NV/DG/FR/whatever as half a god now.

> computer stores matricies? Did somebody tell you to make it your
> business something that's not your business as far as this problem is
> concerned?

Yes, what you tell others to do, don't apply to you. I can see that.

--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

On Sat, 17 Feb 2024 18:57:48 -0600, Physfitfreak wrote:

> On 2/17/2024 9:21 AM, Lester Thorpe wrote:
>> A[i*N + j] = rand() % N;
>
>
> Why aren't you using a two-dimensional array A[i][j] to represent a matrix?
>

There really is no such thing as a 2-D (or N-D) matrix in C or any language.
All storage is strictly linear or 1-D.

The notation "A[i][j]" is translated by the compiler to A[i*N +j].

In addition, since the array was not defined as a 2-D array but
rather as a block of memory with a pointer to the start address
the notion "A[i][j]" would generate a compiler error.

The notation "A[i*N +j]" means to add the vaule i*N+j to the pointer
A which gives the memory location of the data.

On 2/18/2024 5:15 AM, Lester Thorpe wrote:

<snip the usual crazed and misplaced gloating>

> The program is compiled generically:
> gcc -O2 -march=x86-64 -o matmult2 matmult.c
> Run Time Mult 1: 2.72307 seconds
> Run Time Mult 2: 121.731 seconds

> The program is compiled to fit the CPU cache:
> gcc -O2 -march=native -o matmult2 matmult.c
> Run Time Mult 1: 1.9467 seconds
> Run Time Mult 2: 100.011 seconds

> Holy moley! There is roughly a 35% speed improvement
> in the optimized code versus the generic code.

For this extremely contrived example, which does billions of array accesses.

Once again, you can't get your bullshit by me.

> Distro jockeys take serious note. Your distro code
> is junk.

For this one piece of code the biggest improvement comes not from the
-march= flag but from optimization level 3, which contains a bunch of
loop optimizations:

-fgcse-after-reload
-fipa-cp-clone
-floop-interchange
-floop-unroll-and-jam
-fpeel-loops
-fpredictive-commoning
-fsplit-loops
-fsplit-paths
-ftree-loop-distribution
-ftree-partial-pre
-funswitch-loops
-fvect-cost-model=dynamic
-fversion-loops-for-stride

https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

On my Ubuntu WSL system

Multiply 1, N=1024
gcc, no architecture specified
optimizations speed
none 2.635s
-O1 0.413s
-O2 0.455s
-O3 0.144s

-march=x86-64
optimizations speed
none 2.627s
-O1 0.413s
-O2 0.457s
-O3 0.144s

-march=native
optimizations speed
none 2.781s
-O1 0.413s
-O2 0.455s
-O3 0.077s

From the slowest to the fastest is a drastic difference. I'll be sure
to test the -march=native and -O3 options in the future.

https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc.pdf
pg 401

3.18.58 x86 Options
These ‘-m’ options are defined for the x86 family of computers.
-march=cpu-type
Generate instructions for the machine type cpu-type. In contrast to
‘-mtune=cpu-type’, which merely tunes the generated code for the
specified cpu-type, ‘-march=cpu-type’ allows GCC to generate code that
may not run at all on processors other than the one indicated.
Specifying ‘-march=cpu-type’ implies ‘-mtune=cpu-type’.

The choices for cpu-type are:
‘native’
This selects the CPU to generate code for at compilation time
by determining the processor type of the compiling machine. Using
‘-march=native’ enables all instruction subsets supported by the
local machine (hence the result might not run on different machines).
Using ‘-mtune=native’ produces code optimized for the local machine
under the constraints of the selected instruction set.

‘x86-64’
A generic CPU with 64-bit extensions

On Sun, 18 Feb 2024 09:12:07 -0500, DFS wrote:

>
> For this extremely contrived example
>

Certainly. Just like image processing, video processing,
audio processing, graphics processing, etc., etc., are
all "extremely contrived."

Ahahahahahahahahahahahahaha!

As per usual, you haven't a leg to stand on.

>
> Once again, you can't get your bullshit by me.
>

For your edification, I suggest that you enroll here.
They do have an opening for someone of your caliber:

https://about.vidcode.com/girl-scout-summer-camp

Ahahahahahahahahahahahahaha!

The truth is always funny.

On 2/18/2024 6:11 AM, L Thorpe wrote:
> On Sat, 17 Feb 2024 18:57:48 -0600, Physfitfreak wrote:
>
>> On 2/17/2024 9:21 AM, Lester Thorpe wrote:
>>> A[i*N + j] = rand() % N;
>>
>>
>> Why aren't you using a two-dimensional array A[i][j] to represent a matrix?
>>
>
> There really is no such thing as a 2-D (or N-D) matrix in C or any language.
> All storage is strictly linear or 1-D.
>
> The notation "A[i][j]" is translated by the compiler to A[i*N +j].
>
> In addition, since the array was not defined as a 2-D array but
> rather as a block of memory with a pointer to the start address
> the notion "A[i][j]" would generate a compiler error.
>
> The notation "A[i*N +j]" means to add the vaule i*N+j to the pointer
> A which gives the memory location of the data.
>
>

And you want us to use that picture to check for some matrix manipluation?

It is sadism :-) Hehe :)

Matrix algebra is complicated enough by itself. Why not using A[i][j]
for a matrix to point to a certain code behavior so we can focus on the
matrix algebra itself and not what some irrelevant innards of the
computer is.

Unless the answer to your problem _depends_ on the way matrices are
stored in the computer, the way to propose this problem is to at least
use A[i][j] for matrix.

Why sadism? Example: You put two glasses of coke in front of the readers
and tell them to taste them both and find out which one is diet, if they
can; otherwise they're just monkeys. But when we lift the glass to taste
the coke, we find that it is not a glass with coke in it, but a little
statue of a glass with coke in it. So we ask you where's your coke then?
And you reply, "Oh, you need to order that first from Walmart, using the
barcodes you see on the two statues." ...

That's why. Hahhahahah :)

--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

On 2/18/2024 4:15 AM, Lester Thorpe wrote:
> On Sat, 17 Feb 2024 15:21:59 +0000, Lester Thorpe wrote:
>
>> Let's see if the dumb fucks can crack this one.
>>
>
> As predicted, none of the dumb fuck code monkeys explained
> the issue regarding my PERFECT C code.
>
> Ha, ha, ha! One dumb fuck actually had the audacity to claim
> that I messed up the indices. What a stupid cluck! Ha, ha!
>
> Nope. There ain't nothing amiss with my PERFECT C code.
>
> The problem is CACHE HITS/MISSES.
>
> The CPU operates only on cache. RAM is essentially just another
> disk drive. Data and instructions from RAM memory are loaded
> into the cache and the CPU processes that cached data.
>
> In the first matmult method, the data is accessed sequentially
> so that there are minimal cache misses.
>
> In the second matmult method, the data access jumps around
> the array and this increases the cache misses which severely
> slows performance.
>
> Now for another shocker.
>
> The program is compiled generically:
>
> gcc -O2 -march=x86-64 -o matmult2 matmult.c
>
> Result:
>
> Run Time Mult 1: 2.72307 seconds
>
> Run Time Mult 2: 121.731 seconds
>
>
> The program is compiled to fit the CPU cache:
>
> gcc -O2 -march=native -o matmult2 matmult.c
>
> Run Time Mult 1: 1.9467 seconds
>
> Run Time Mult 2: 100.011 seconds
>
>
> Holy moley! There is roughly a 35% speed improvement
> in the optimized code versus the generic code.
>
> Distro jockeys take serious note. Your distro code
> is junk.
>

But one could find this solution, if you had used A[i][j] for matrix
too. Even I, not knowing jack about RAM or CACHE, could just check and
see how matrix A[i][j] is stored and its elements accessed in this
problem, then see the cause of the inefficiency.

It's a nice problem regardless. In fact I remember in numerical methods
class they taught us to avoid making that unnecessary jumping back and
forth necessary.

--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

On 2/18/2024 2:11 PM, Physfitfreak wrote:
> On 2/18/2024 4:15 AM, Lester Thorpe wrote:
>> On Sat, 17 Feb 2024 15:21:59 +0000, Lester Thorpe wrote:
>>
>>> Let's see if the dumb fucks can crack this one.
>>>
>>
>> As predicted, none of the dumb fuck code monkeys explained
>> the issue regarding my PERFECT C code.
>>
>> Ha, ha, ha!  One dumb fuck actually had the audacity to claim
>> that I messed up the indices.  What a stupid cluck!  Ha, ha!
>>
>> Nope.  There ain't nothing amiss with my PERFECT C code.
>>
>> The problem is CACHE HITS/MISSES.
>>
>> The CPU operates only on cache.  RAM is essentially just another
>> disk drive.  Data and instructions from RAM memory are loaded
>> into the cache and the CPU processes that cached data.
>>
>> In the first matmult method, the data is accessed sequentially
>> so that there are minimal cache misses.
>>
>> In the second matmult method, the data access jumps around
>> the array and this increases the cache misses which severely
>> slows performance.
>>
>> Now for another shocker.
>>
>> The program is compiled generically:
>>
>> gcc -O2 -march=x86-64 -o matmult2 matmult.c
>>
>> Result:
>>
>> Run Time Mult 1: 2.72307 seconds
>>
>> Run Time Mult 2: 121.731 seconds
>>
>>
>> The program is compiled to fit the CPU cache:
>>
>> gcc -O2 -march=native -o matmult2 matmult.c
>>
>> Run Time Mult 1: 1.9467 seconds
>>
>> Run Time Mult 2: 100.011 seconds
>>
>>
>> Holy moley!  There is roughly a 35% speed improvement
>> in the optimized code versus the generic code.
>>
>> Distro jockeys take serious note.  Your distro code
>> is junk.
>>
>
>
> But one could find this solution, if you had used A[i][j] for matrix
> too. Even I, not knowing jack about RAM or CACHE, could just check and
> see how matrix A[i][j] is stored and its elements accessed in this
> problem, then see the cause of the inefficiency.
>
> It's a nice problem regardless. In fact I remember in numerical methods
> class they taught us to avoid making that unnecessary jumping back and
> forth necessary.
>
>
>
>
>

I have a feeling if you had written the code in FORTRAN the result would
by the opposite of what you got. The inefficient one in C would become
the efficient one in FORTRAN. FORTRAN stored matrices by columns, not by
rows. At least in the version of it we used back then.

--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

On Sun, 18 Feb 2024 14:11:05 -0600, Physfitfreak wrote:

>
> It's a nice problem regardless. In fact I remember in numerical methods
> class they taught us to avoid making that unnecessary jumping back and
> forth necessary.
>

Cache is the hidden devil in all C programming.

The C programmer has to always be very careful that his code includes
proper cache management or else he will incur serious problems.

This is no illusion. Check out this article:

https://johnnysswlab.com/make-your-programs-run-faster-by-better-using-the-data-cache/

The competent C programmer has to be a master of cache.

On 2/18/2024 12:42 PM, Lester Thorpe wrote:
> For your edification, I suggest that you enroll here.
> They do have an opening for someone of your caliber:
>
> https://about.vidcode.com/girl-scout-summer-camp

With his female brain he'll love it.

--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

On 2/18/2024 3:35 PM, Lester Thorpe wrote:
> https://johnnysswlab.com/make-your-programs-run-faster-by-better-using-the-data-cache/
>
> The competent C programmer has to be a master of cache.
>

Thanks. I'll keep the link till I relearn C.

--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

On Sun, 18 Feb 2024 16:43:57 -0600, Physfitfreak wrote:

> Thanks. I'll keep the link till I relearn C.

Follow the link to geeksforgeeks.org to discover Lester's motherlode.

On 2/18/2024 1:42 PM, Lameass Larry Piet wrote:
> On Sun, 18 Feb 2024 09:12:07 -0500, DFS wrote:
>
>>
>> For this extremely contrived example
>>
>
> Certainly. Just like image processing, video processing,
> audio processing, graphics processing, etc., etc., are
> all "extremely contrived."
>
> Ahahahahahahahahahahahahaha!
>
> As per usual, you haven't a leg to stand on.

As per usual, you're a phony baloney who pretends he writes
sophisticated C code for image/video/audio/graphics.

What we have in common is this: we both know the truth about your
nonexistent "C Programmer Extraordinaire" skillz.

>> Once again, you can't get your bullshit by me.
>>
>
> For your edification, I suggest that you enroll here.
> They do have an opening for someone of your caliber:
>
> https://about.vidcode.com/girl-scout-summer-camp
>
> Ahahahahahahahahahahahahaha!
>
> The truth is always funny.

ALL your moments of truth happen in simpleton bash scripts.

DFS <nospam@dfs.com> wrote:
>On 2/18/2024 1:42 PM, Lameass Larry Piet wrote:
>> On Sun, 18 Feb 2024 09:12:07 -0500, DFS wrote:
>>
>>> For this extremely contrived example
>>
>> Certainly. Just like image processing, video processing,
>> audio processing, graphics processing, etc., etc., are
>> all "extremely contrived."
>>
>> Ahahahahahahahahahahahahaha!
>>
>> As per usual, you haven't a leg to stand on.
>
>As per usual, you're a phony baloney who pretends he writes
>sophisticated C code for image/video/audio/graphics.
>
>What we have in common is this: we both know the truth about your
>nonexistent "C Programmer Extraordinaire" skillz.

From what he's posted, I could believe he has the skillz to download
someone else's work and compile it, since his distro doesn't even
distribute shit as binaries already, which is a really great way to
advocate the use of Linux BTW, but the idea that his goofy programs to
do simple and pointless math problems, has anything to do with video
processing/etc., is laughable, yes. Russell is a fraud just like DJT.

--
Joel W. Crump

Amendment XIV
Section 1.

[...] No state shall make or enforce any law which shall
abridge the privileges or immunities of citizens of the
United States; nor shall any state deprive any person of
life, liberty, or property, without due process of law;
nor deny to any person within its jurisdiction the equal
protection of the laws.

Dobbs rewrites this, it is invalid precedent. States are
liable for denying needed abortions, e.g. TX.