Thread 106560464

How would you update this for 2025?

I'd start by making it actually correct.

the cow being processed on the P cores anmd the divvying up is done by the E cores

https://en.wikipedia.org/wiki/Amdahl's_law
No matter how many cores you have you're never gonna get more than a 2x speedup outside of benchmarks. Although offloading I/O to a separate core is good but that's a separate issue and an issue with current operating systems not fundamental to computers.

>>106560473
If you can make a simple version, I will happily do the legwork and make it at least A-tier. We can work from their if needed; I might get lucky and nail it first try.

The day I see multiple cores being used simultaneously to emulate one cpu in real time, I'll know something has improved.

>>106560464 (OP)
im gay

>>106560609
TFD

>>106560464 (OP)
updated for 2025

>>106560464 (OP)
>How would you update this for 2025?
slice the cow in 8 big parts and 16 smaller parts. the 8 big parts go into pee cores, smaller parts into estrogen cores

>>106560464 (OP)
>2025 Windows 11 version:
>Loads a webbrowser to execute javascript.
>Checks if Cow2Beef.exe is not a malware.
>Loads a webbrowser again to execute javascript.
>Sends Cow2Beef.exe to Microsoft and waits for its approval to execute this.
>Loads a webbrowser again to execute javascript to treat the reply from Microsoft.
>Displays an ad, because fuck you.
>If ok, checks if Cow2Beef.exe does not contain hate speech or lolicon.
>If ok, runs Cow2Beef.exe at last
>46 seconds

> >>106560952
> >>If ok, checks if Cow2Beef.exe does not contain hate speech or lolicon.
>BETTER A MILLSTONE
>SLAUTGHTER PEDOS


>JESUS SAYS GOUGE OUT MALLLEESS EYES: FUCK YOUR FREEDOM OF SPEECH!

>>106560486
Amdahl's law is retarded and has no relation to reality. You have a synchronous algorithm, which cannot be parallelized, hence the "parallel portion" is zero. We can then write a parallel version of the algorithm where the T units of work from the algorithm are spread across N cores, hence taking time T/N. However, there is additional work we have to do for the parallel algorithm which is not done in the synchronous algorithm. Define the "splitting cost" S to be the amount of work it takes to split work between two cores. Then the total time it takes to run the parallel algorithm is P(N) = T/N + S log N. Notice that the overhead varies in the number of cores, hence amdahls law doesn't apply. This function is minimized when dP/dN = 0 = -T/N^2 + S/N/ln2; T/N^2 = S/N/ln2; Nmax = ln2 T/S; where it reaches its minimum Pmin = S/ln2 + S log (ln2 T/S). Notice that this is basically constant in T, hence the total time to run the algorithm hardly varies no matter how much work needs to be done. This assumes we have sufficiently many cores, but usually the splitting cost is minuscule compared to the total work. Eg the splitting cost might be 1ms. For an algorithm that takes 10 seconds to run, this gives us P(1000) = 10/1000 + .001 log 1000 = .01 + .01 = .02s, and Pmin = P(7000) = .0015 + .013 = .014s. Overall we get a speedup of 700x which is pretty good.

>>106560464 (OP)
>food analogy

>>106560486
>No matter how many cores you have you're never gonna get more than a 2x speedup outside of benchmarks.
Wrong. Literally wrong. It depends on what fraction of the program parallelizes, what the cost of parallelizing is, and how much time is spent communicating and coordinating. You can definitely win big in some cases.
>>106561141
>Amdahl's law is retarded and has no relation to reality.
Also wrong, but the rest of what you wrote is right.
Amdahl's law is true enough, but you need to be very careful with what it actually says. Switching to a natively parallel algorithm with a lot of cores can win massively, but if most of the code's execution time is dominated serial or effectively-serial operations, adding more cores doesn't really help.

>>106560464 (OP)
multi-cow processing heh