I Said "Task A"tony tony chopper wrote:Take convolution, in its simplest form it's just a few operations, in its fast form it's quite complex, involves partitioning using FFTs.For task A, the sum of instructions*cpu cycles that will complete the task will always be faster than more instructions*cpu cycles.
You failed at understanding and replied:
=Task Atony tony chopper wrote:in its simplest form it's just a few operations
=Task Btony tony chopper wrote:in its fast form it's quite complex, involves partitioning using FFTs
You are fairly knowledgeable, but you are not as good at communicating with people.
I am sure you know that these two are NOT the same thing, but you used it as an argument = fail.
So lets put them both as text string value of variable "Task A":
For convolution in its simplest form, the sum of instructions*cpu cycles that will complete the task will always be faster than more instructions*cpu cycles.
Get it ?For convolution in its fast form, the sum of instructions*cpu cycles that will complete the task will always be faster than more instructions*cpu cycles.
I am fully aware of all that, i started programming at about 10 years old (sure i never achieved a status of a computer programming wizard, but i know my stuff)tony tony chopper wrote:(& even though you wanted to write something that sounds like something that can't be argued, yes it still can. The CPU cycle an instruction takes isn't its only property. Its ability to pair (& with what it can), its behavior with cache, its possible penalties..
If by "instructions*cpu cycles" i mean lets say 100 total cycles, then 110 total cycles achieving the EXACT SAME THING will be less optimized code and will take longer to compute.
So 100 cycles slower than 110 cycles.tony tony chopper wrote:yes, more instructions*cpu cycles can end up faster)
Yeah right...
