>>55045375
>i dont know what is the instruction pipeline
single core cpus already execute multiple instructions per clock
also leave the booze

>>55045375
>doing the exact same thing but at a higher clock
I hope you aren't a CS student because this is literally fourth week knowledge. Look into how a CPU executes instructions (really simple if you stay at the abstraction level you are currently speaking at)

And no, you don't seem like a retard.

>>55045375
Processor core redundancy is already a thing in highly mission/safety critical systems. What you're asking for is literally multithreading.

>>55045375
wow ur a genius op, no1 thought of that 1 before

better file for the patents now!

>>55045496
that wasn't what I asked. I asked if you could overclock cpus to a point where a normal running cpu would already fail, and keep all results correct through redundancy.
>>55045537
I also asked for data about how much the error rate would increase. That's not "fourth week knowledge" (also I only study "media computer science", I know I'm cancer, but I want to improve)
I know how CPU instructions are executed, my point was the potential performance improvement.
>>55045552
no it isn't

>>55045375
So what's the difference between that and multithreading?

>>55047958
Multithreading makes multiple threads happen either on the same core or other cores.
Processor core redundancy lets the same instructions with the same data run on multiple cores. You can have multithreading on these cores, but it would behave exactly like a single core. All cores would switch threads at the same time (all working the same thread, generating the same results etc)

>all cores outputting garbage
>"mistakes can be easily spotted and corrected"

You're presuming there's a known good answer to check against. If we knew what the answer was we wouldn't need to calculate it.

>>55048153
that's exactly why I made this thread. If a core overclocked to 6ghz makes a mistake every 1000 calculations, it'll still fail almost instantly. If you have 4 of them running, comparing their results, it's VERY rare that all 4 get to the same wrong result.
My question was: is there data on how frequent miscalculations are on high clocks?

>>55048200

You're making the faulty assumption that "mistakes" are independently distributed. Your idea is royally fucked if there's any kind of covariance.

>>55048200
I think your mistake was asking about this on 4chan, find someone with a high position inside a CPU-making company and ask them that or find a way to super-overclock some CPU.

go change teh world, op

>>55048255
That was my idea, but it's weekend and I can't currently access my Intel/AMD/Nvidia CEOs

>>55046203
>no it isn't
Well, it's not, but the problem you want to solve was solved by multithreading.

>>55048254
Again this is exactly what I was asking for. I just wanted to know if this would be a feasible way to get single core performance up. The consumer market doesn't need 20 core CPUs, and chip manufacturers don't know what to do with all those transistors moore's law gives them. Basically I was too lazy to search for some scientific research done in this exact field. It's also not an Idea so unbelievably innovative that no Intel engineer didn't already have it.

>>55048300
No you stupid fucking cunt it isn't.
Multithreading is good for stuff that is parallelizable. But many problems need to be solved sequential and therefore you just can't throw more threads at them and get better results. Overclocking always works, as long as you get the data in fast enough and the results aren't wrong. The results-being-wrong may be solved by redundancy.

>>55045375
You seem to assume that the failure of CPUs outside of their operation range is somehow a statistical process. It's really not (at least not necessarily). It is very likely that if a CPU fails at a certain clock, it will always fail in very similar ways. So you won't have three of five cores giving you the right answer, you will probably get the wrong answer from all cores. Also, it's very possible that actually all cores give you different wrong answers. Then you can't decide with which one to go and funny stuff like that is useless for computation.

Anyway, if something like that is at all possible, the clock range would be tiny and it would be extremely unstable and hardly predictable.

>>55045375
You're assuming "spotting and correcting" mistakes is quicker than resending the instruction through the pipeline, which isn't realistic.

>>55045375
CPUs already have branch prediction technology that tries to do this. Trying to use two cores to work around branch misses is incredibly expensive.

>>55048369
But you don't have data on that. There are 6700ks being overclocked to over 7ghz, so these frequencies ARE possible. Only the error rate at low voltages increases enough to make an OS crash. But when you consider that billions of calculations being done per second and one critical one can fuck up the OS, the error rate could still be extremely low. Low enough to be countered by redundancy

>>55048320

I think you also have a misunderstanding that all CPU instructions are created equal. They aren't. Some things can't tolerate any kind of mistake eg. locks

>>55048425

>One liquid nitrogen cooling hits the mainstream

>>55048388
>instruction
you don't need a lot of transistors to have a 64 bit xor. that's spotting done.
for correction, there sure are ways I'm not educated enough to know, that are as fast and efficient. You don't need an algorithm for that, you can build it in hardware, which is very fast

>>55048449

Again. OP if there's covariance you're fucked. If executing instruction X core 1 results in a mistake, we should maybe believe that similar mistakes are more likely than average on other cores.

>>55048428
but if each of them works on their own data which is synced by some external chip or some shit... I don't know man, I'm just throwing the idea at the wall

>>55048282
My dad works at Nintendo and he says you're full of shit anyway faggot

>hey /g/, what if we quartered the performance while raising the electrical and cooling costs by 100%?

>>55045375
Hey OP, sightly off topic but I think this is cool:

>Studies by IBM in the 1990s suggest that computers typically experience about one cosmic-ray-induced error per 256 megabytes of RAM per month.

Sauce: http://www.scientificamerican.com/article/solar-storms-fast-facts/

>>55048425
Even if it is a strictly stochastic process, it's just insane to use that as a basis for a deterministic computer. Especially because it's highly unstable—maybe some instruction has a failure rate of 10% at 65°C, but a failure rate of 99% at 67°C. Shit like that can happen and will ruin your whole system. It's just unpredictable and therefore not fit for a computer. At least not a traditional computer. It's fine for quantum computers, but those things at least have some other advantages.

>>55048543
like they do with the branch prediction logic which takes about 95% of a processor die?

>>55045375
> error rates increase with higher clock speeds
> Mistakes could easily be spotted and corrected

You might want to think more before you say that.

Suppose you had 8 cores, all duplicating each others' calculations -- running so fast that occasionally a core will produce the wrong result.

Now, let's say that all 8 cores execute the same instruction (say: R0=R1+R2) and you get the following 8 results in R0: 4, 4, 5, 4, 6, 4, 3, 4. At this point, you need the CPU to examine these 8 values and do the following:

(1) Detect if there is any disagreement among the 8 different results.

(2) If so, figure out which result is correct.

(3) Forcibly deploy the correct answer. In the example above, the cores that did not get the correct answer (4) must all have their R0 changed to 4 before proceeding to the next instruction.

Now, think about how many additional clock cycles the above three things will take to implement. (1) must be done after every instruction. (2) and (3) must be done for every error recovery.

Also, think about the case where it's not possible to determine the correct answer. For example, let's say that the 8 cores yield the following results in R0: 3, 5, 4, 6, 4, 3, 5, 4. In that case, the most common result was obtained by less than 50% of the cores, which casts a serious doubt about whether it's even the correct result. In this case, what algorithm would you use to determine the correct answer? And how many additional clock cycles would it take to implement that algorithm?

>>55048624
>you need the CPU to examine these 8 values
no you can just xor these results pretty easily. if there's any disagreement, that can be detected immediately. Similarly, you could build a logic that takes the most likely result (say if 5/8 results are the same) and accepts it. You can build all that in pretty simple and small (and fast) hardware. This isn't a very hard task (look up branch prediction and how complex that shit is. This approach is childs play compared to that)

>>55045375
>Mistakes could easily be spotted and corrected
No they couldn't. Within one instruction, a processor does a lot of things. If it fails at any point due to the clock frequency being too high for logic gates to propogate signals within the appropriate number of cycles, then you get a value which is complete garbage - which means ECCs wouldn't help at all. Even if you compared outputs at different stages in the pipeline, you'll still be unable to recover an error that occurs from being unable to read from memory in time with the high clock frequency

>>55045375
Not exactly this, but stochastic, analog computing has been re-surging in research popularity and follows much the same approach.

While 8 or 12 simultaneous attempts at solving a problem won't produce a viable stochastic solution, 1000 attempts will. This is where analog computing really takes over.

Analog computers are the only way we'll continue to beat moore's law and produce effectively-faster hardware, short of quantum computing.

>>55048699
>XOR'ing 8 inputs and outputting the most common input is much faster than a single clock cycle

this can't be true

>>55048699

You're correct that the detection is a simple xor.

But what if there is no "most likely result"? What if only 3 of the 8 cores agree on the answer? What if only 2 of the 8 cores agree? What algorithm will you use to determine the correct answer in those cases? Actually, I don't even care how many clock cycles this would take -- I'm just trying to figure out what the algorithm would be.

Also, you seem to think that taking the "most likely result" and accepting can be done without any cost. But that correct value has to be inserted into the erroneous register, which takes an extra clock cycle and could break the pipeline. All 8 cores would have to be stalled if the pipeline breaks on any of them -- because the cores cannot be allowed to get out of sync.

> You can build all that in pretty simple and small (and fast) hardware.

If you focus on making it as fast as possible, that would greatly increase the number of gates necessary. The hardware size would grow massively.

>>55048797
>in order to come up with good new ideas, existing concepts must be sitting in your brain at the same time.

actually given modern IPCs I think its very possible.

in fact for a hypothetical bespoke redundant processor, that XOR can be a discrete module on silicon with no relation to the system clock whatsoever

>>55048828
>What algorithm will you use to determine the correct answer in those cases?
you just roll back and calculate again.
Branch prediction does exactly that already (on YOUR CPU right now). Yes it's a bit expensive, but manufacturers think it's worth it, so...

(maybe you could have a designated shitting core, which runs at normal speed and WILL calculate a correct result in that case.)