The delay gap between 600MHz DDR memory interface for CPU with 500MHz clock is smaller than the delay gap for 3.4GHz CPU and 800MHz DDR interface. The 500MHz CPU can get away with smaller cache or less cache levels. 3.4GHz CPU cannot - there is not enough computation volume available to mask delay of several dozens of clock cycles. There is not enough computation available in 8 SPARC Tx Niagara threads for one 1.8GHz core, even with their scout thread tech (to reduce stalling thread does resolve future addresses and prefetching data when stalled). What to say about 3.4GHz CPU with only two threads per core? It certainly will stall during cache misses for random memory access with (relatively) slow DDR interface.
In short, if you reduce clock count for Intel i7 to 500 MHz, you will have: reduced pipeline length from 15-20 cycles to 5-6, proportionally to clock frequency reduction, and reduced stalling penalty for cache misses. Shorter pipeline does not do much harm in case of mispredicted branches. Shorter pipeline also means quicker computation and less stalling in Read-After-Write command chains. To sum, you will have more performance per clock cycle than in higher frequencies.
(this is why mobile processors are mostly much slower than desktop counterparts)
So, on 7Zip problem hypothetical 500MHz i7 will be faster than just 3.4GHz i7 scaled down by 34/5 factor. I think difference will be two-three fold in favor of 500MHz i7 (mostly due to shorter pipeline, partly due to less severe penalties).
This gives that hypothetical 500MHz i7 a speed of 2.5-3MIPS/MHz.
PS
Reduction of pipeline from N stages to N-1 stage gives speed boost of about 1/N. E.g., I observed in simulation speed boosts of about 15%-20% when pipeline length went from 5 to 4 stages. This was in "real" clock-accurate simulation, with proper simulation of DDR memory and controller, cache and their delays. The tests were also real, like string and graphics handling/processing.
The delay gap between 600MHz DDR memory interface for CPU with 500MHz clock is smaller than the delay gap for 3.4GHz CPU and 800MHz DDR interface. The 500MHz CPU can get away with smaller cache or less cache levels. 3.4GHz CPU cannot - there is not enough computation volume available to mask delay of several dozens of clock cycles. There is not enough computation available in 8 SPARC Tx Niagara threads for one 1.8GHz core, even with their scout thread tech (to reduce stalling thread does resolve future addresses and prefetching data when stalled). What to say about 3.4GHz CPU with only two threads per core? It certainly will stall during cache misses for random memory access with (relatively) slow DDR interface.
In short, if you reduce clock count for Intel i7 to 500 MHz, you will have: reduced pipeline length from 15-20 cycles to 5-6, proportionally to clock frequency reduction, and reduced stalling penalty for cache misses. Shorter pipeline does not do much harm in case of mispredicted branches. Shorter pipeline also means quicker computation and less stalling in Read-After-Write command chains. To sum, you will have more performance per clock cycle than in higher frequencies.
(this is why mobile processors are mostly much slower than desktop counterparts)
So, on 7Zip problem hypothetical 500MHz i7 will be faster than just 3.4GHz i7 scaled down by 34/5 factor. I think difference will be two-three fold in favor of 500MHz i7 (mostly due to shorter pipeline, partly due to less severe penalties).
This gives that hypothetical 500MHz i7 a speed of 2.5-3MIPS/MHz.
PS Reduction of pipeline from N stages to N-1 stage gives speed boost of about 1/N. E.g., I observed in simulation speed boosts of about 15%-20% when pipeline length went from 5 to 4 stages. This was in "real" clock-accurate simulation, with proper simulation of DDR memory and controller, cache and their delays. The tests were also real, like string and graphics handling/processing.