>Friend runs his implementation of a DSP program with some ridiculous parameters
>On his Thinkpad(tm) it takes ~3 seconds to process a 30 second .raw file
>Sends it over to me
>No recompiling, no nothing, my computer takes >10 minutes to do the same thing.
How can this be happening? We both run Ubuntu but he has a 2.8 GHz I7, while I have an A4-5000. both are quad-core but it's a single-threaded app so it only takes up 25% of the CPU
>AMD Laptop
>expecting anything to happen fast
>A4
there's your're answer my guy
>A4-5000
>quad core
LOL
You have a slow ass cpu my dude, A4 is homeless tier level of poor.
the processor cannot be responsible for such a drastic difference
>Direct Sound Program program
It's Digital Signal Processing you ponce
It absolutely can given it's 1.5GHz at AMD's crappy IPC.
Also, does he have an SSD?
>what are hardware instruction sets
it loads the entire 4.5 MiB file as an array of int_16 at once. The point of comparison arose when I had made my implementation worked on iostreams with a circular buffer that dynamically loaded the data as it was being processed, which reduced the memory footprint to 500 KiB, but may have increased CPU usage.
More efficient pipelining on the i7, better built-in instruction sets, faster clockspeed...
There's tons of reasons why it would run quickly on his machine but not on yours.
Yeah but the difference still seems a bit ridiculous. It's not like you can pipeline more than 5 instructions per step, and the machine code is exactly the same because it's the exact same executable
recompile it then for your machine
still no faster. I may have underestimated the speed since it does do around 20k samples/second which is only around, idk, 30 times slower than his computer so it doesn't seem *that* unreasonable, but i'm still staggered by the difference in that particular application, which is basically multiplying and adding a whole bunch of floats
Ran out of ram and you're using a HDD like the poorfag you are.
literally no
the real answer seems to be that it enter an infinite loop on my computer for some reason
oh yeah i forgot to mention, the program doesn't actually terminate on my PC, i just get bored of waiting after a few minutes
No wait it does terminate, I'm a retard who can't see where the processing is happening
performance difference singlecore is like 6x, then
thermal throttling because cheap cpu = usually cheap everything, + IPC
ask your friend for compiler flags he used.
>2.8ghz i7 (most likely has 3.2ghz turbo boost enabled as well)
>vs a sub-walmart-laptop-tier CPU
wow easiest troubleshooting ever
Oh and one last thing: I now realize that when he told me that the processing was done (I asked him "hey, the terminal is not updating, doesn't that mean the processing is finished?" and he said "oh yes") he was wrong. what actually happened is, only the samples were loaded into memory, and he probably terminated the program while it was still processing the samples without realizing it, and the output file he showed me may have been a residue from an earlier run. (you know, it's kind of hard to judge whether a low-pass filter has done it's job correctly when you don't know what Cutoff frequency it's at). Come to think of it, the output of a filter that works by averaging values over 2 seconds should basically be a straight line with no components higher than 0.5 Hz.
So to recap: I'm retarded, my friend is retarded, and every single one of you is retarded
Idk what the fuck others were thinking but this sounded more like a programming bug from the start. Why the fuck are people shitting on the processor for no reason?
3 seconds vs 10 minutes = 200x difference you fucking retards
Because the only thing people know on this board is which de/gpu/cpu/os to use and why yours is shit
I want gookmoot to just end this all, already.
Hiro, if you're reading, wipe us all the fuck out right now.
really the only problem is that people from Sup Forums use their computer to play video gayms all the time, and then society tells them that because they use their computer a lot, they must automatically know everything about computers.
So now you have a bunch of children screaming at each other every time nvidia or amd release a new graphics card or something
> averaging values over 2 seconds should basically be a straight line with no components higher than 0.5 Hz.
except that's now how a moving average works you retard. it's not a brick-wall filter
l2signalprocessing101
Anyway, the final result is, my implementation, using iostreams and a circular buffer turns out to be ~4 times slower compared to his implementation that uses a static array of ints, with the end result being 100% indistinguishable (as in, when you load both outputs into audacity, invert one of them and play, the output is a constant 0). His program uses 9 times more memory for obvious reasons, but how much is 4.7 MiB, in the modern day, really.
Other difference is that my code is more versatile, and imho, prettier. I wrote a ringmod and a delay by changing just one virtual function as well as the constructor for the class
When I'm going to be doing actual signal processing I'll just fuse a resistor and a capacitor together and it'll be great and analog pure warm hifi signals brah. Digital Sound is not real amirite
>A4-5000
>Clockspeed: 1.5 GHz
>No of Cores: 4
>Typical TDP: 15 W
Analog can never achieve a brick-wall filter. Such a filter requires anticausal response (sinc impulse response).
Furthermore your 1-resistor-1-cap filter will only achieve a single pole rolloff so you'll only get 20dB/decade and only 3db attenuation at your pole frequency.
dude I know. I was hoping to attract the attention of the Audiopedophile crowd
AVX
V
X
>30 times slower than his computer
this is easily obtainable if you just chain a couple factors together
SIMD instructions, there's ~4x. pipelining, there's ~4x. your clock rate is 2x as slow, 4 * 4 * 2 = 32 and we're already there
i have no idea if these are the actual factors, to know that you have to benchmark. try perf, and if that doesn't work try likwid