Thanks for sharing that, that's a very good article. What it demonstrates is that for a given task there is an irreducuble algorithmic complexity, with the choice to put that into the instruction set architecture and/or the implementing hardware (compilation aside). But then if you change the task .....
I never really understood RISC vs CISC when it first came up - yes, I am that old - so now I'm pleased to hear it now doesn't matter. A non-question for a non-problem. But it is right in saying that the CPU will nearly always beat DRAM response, the speed of light being what it is : you can consider circuitry as fancy waveguides if you like and proximal beats distal nearly always. Now if only we had an ASIC for every eventuality. :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Thanks for sharing that, that's a very good article. What it demonstrates is that for a given task there is an irreducuble algorithmic complexity, with the choice to put that into the instruction set architecture and/or the implementing hardware (compilation aside). But then if you change the task .....
I never really understood RISC vs CISC when it first came up - yes, I am that old - so now I'm pleased to hear it now doesn't matter. A non-question for a non-problem. But it is right in saying that the CPU will nearly always beat DRAM response, the speed of light being what it is : you can consider circuitry as fancy waveguides if you like and proximal beats distal nearly always. Now if only we had an ASIC for every eventuality. :-)
Cheers, Mike.
What would be cool is an on the fly re-programmable ASIC, then each need could be addressed by the programmers and handled by the device. Probably too expensive to make and then repair when it breaks but cool anyway.
Thanks for sharing that, that's a very good article. What it demonstrates is that for a given task there is an irreducuble algorithmic complexity, with the choice to put that into the instruction set architecture and/or the implementing hardware (compilation aside). But then if you change the task .....
I never really understood RISC vs CISC when it first came up - yes, I am that old - so now I'm pleased to hear it now doesn't matter. A non-question for a non-problem. But it is right in saying that the CPU will nearly always beat DRAM response, the speed of light being what it is : you can consider circuitry as fancy waveguides if you like and proximal beats distal nearly always. Now if only we had an ASIC for every eventuality. :-)
Cheers, Mike.
What would be cool is an on the fly re-programmable ASIC, then each need could be addressed by the programmers and handled by the device. Probably too expensive to make and then repair when it breaks but cool anyway.
1. if it was reprogrammable/reconfigurable, it would no longer be an 'ASIC'
2. what you're describing is exactly what a FPGA is.
Thanks for sharing that, that's a very good article. What it demonstrates is that for a given task there is an irreducuble algorithmic complexity, with the choice to put that into the instruction set architecture and/or the implementing hardware (compilation aside). But then if you change the task .....
I never really understood RISC vs CISC when it first came up - yes, I am that old - so now I'm pleased to hear it now doesn't matter. A non-question for a non-problem. But it is right in saying that the CPU will nearly always beat DRAM response, the speed of light being what it is : you can consider circuitry as fancy waveguides if you like and proximal beats distal nearly always. Now if only we had an ASIC for every eventuality. :-)
Cheers, Mike.
What would be cool is an on the fly re-programmable ASIC, then each need could be addressed by the programmers and handled by the device. Probably too expensive to make and then repair when it breaks but cool anyway.
1. if it was reprogrammable/reconfigurable, it would no longer be an 'ASIC'
2. what you're describing is exactly what a FPGA is.
Thanks for sharing that,
)
Thanks for sharing that, that's a very good article. What it demonstrates is that for a given task there is an irreducuble algorithmic complexity, with the choice to put that into the instruction set architecture and/or the implementing hardware (compilation aside). But then if you change the task .....
I never really understood RISC vs CISC when it first came up - yes, I am that old - so now I'm pleased to hear it now doesn't matter. A non-question for a non-problem. But it is right in saying that the CPU will nearly always beat DRAM response, the speed of light being what it is : you can consider circuitry as fancy waveguides if you like and proximal beats distal nearly always. Now if only we had an ASIC for every eventuality. :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Mike Hewson wrote: Thanks
)
What would be cool is an on the fly re-programmable ASIC, then each need could be addressed by the programmers and handled by the device. Probably too expensive to make and then repair when it breaks but cool anyway.
mikey wrote: Mike Hewson
)
1. if it was reprogrammable/reconfigurable, it would no longer be an 'ASIC'
2. what you're describing is exactly what a FPGA is.
_________________________________________________________________________
Ian&Steve C. wrote: mikey
)
I did not know that, interesting.