SlowSpyder
Lifer
I paid something stupid cheap like $37 for a 1600MHz Duron that could crack 2300Mhz. That is probably my most memorable. You have to love those cheapies that approach a 50% oc! 😀
-
We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.
can you compare a new cpu to a 20 year old one?
Page 2 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
I paid something stupid cheap like $37 for a 1600MHz Duron that could crack 2300Mhz. That is probably my most memorable. You have to love those cheapies that approach a 50% oc! 😀
Don't forget memory hierarchy scaling.
Over time, if memory requirements keep at a constant factor, the application's memory footprint "moves up" the cache hierarchy.
Just for fun did I use a virtual machine with DOS 5 and Turbo Pascal. My 30.000 line chess program from the 90ties experienced a 3.000 fold improvement vs. the original IBM PC - largely due to the fact that the application fitted in the level 1 cache. Increasing the speed-up even beyond the clock, ILP, micro-architecture improvements of the core CPU.
rgds,
Andy
Over time, if memory requirements keep at a constant factor, the application's memory footprint "moves up" the cache hierarchy.
Just for fun did I use a virtual machine with DOS 5 and Turbo Pascal. My 30.000 line chess program from the 90ties experienced a 3.000 fold improvement vs. the original IBM PC - largely due to the fact that the application fitted in the level 1 cache. Increasing the speed-up even beyond the clock, ILP, micro-architecture improvements of the core CPU.
rgds,
Andy
(sic)Klown12
Senior member
Last edited:
tweakboy
Diamond Member
I need HT. I use Sonar X2 Producer x64 24bit/192hz @ 2ms. In my app it shows your usages.. it shows 8 , so it sorta becomes a 8 cores, HT 64bit app... You should not say you dont need HT blah. First see what they are going to do if your gonna shut it off, alto on would be better giving you up to 40 percent increase in say Photoshop,, etc..
Matt1970
Lifer
Consider that at the time the Pentium 75 was released your whole operating system fit on a handful of 1.4 meg floppy disks. Windows 3.1 absolutely flew on a Pentium.
TerryMathews
Lifer
Happened with the 1.6LV Xeons too. Stepping D1 could run all day long at 3.2GHz.
Had a pair of those for a long, long time.
james1701
Golden Member
One thing to remember, information was not as wide spread then when the Pentium series were launched like it is today. I can remember just dreaming about getting a Pentium chip just to watch how fast it could decompress ARJ files. It was a big step up for many 486 machines at the time.
AndyEI891627 said:
There's no doubt that memory is now much faster. But let's look at a few things
1) Original IBM PC is 4.7 MHz. Core i5 3570K is 3.4 GHz. That's a 723x increase just in clock speed.
2) On the 8088, the fastest instruction was mov reg,reg at 2 cycles. Now we're up to at least a 1440x increase and probably more already since there are many more instructions (especially integer instructions) that effectively execute in 1 cycle on Ivy Bridge
3) Ivy Bridge is also super scalar and has speculative execution.
The above 3 can absolutely give a 3000x increase in performance. Try disabling L1, L2, and L3 caches and run again. Should be interesting.
Don't get caught by the increase in bandwidth. The primary bottleneck today is latency (access time). This access time (measured in nanoseconds) increased since the IBM PC days only 4-5 fold. That's the primary reason why we got one level of cache, then a second and now a third.
These days, one main memory access incurs a CPU wait time up to 200-400 CPU cycles. During the IBM PC days only poorly designed systems had wait states for main memory access.
All the huge performance increases listed by you have one important requirement. The data need to be in the cache. Most benchmarks are so small, that they fit into the cache hierarchy - if your application as well, that's fine. If your data is bigger than the cache than your computational perf drops up to 10 fold (and sometimes even more) due to memory stalls.
Simple example:
Try adding the elements of 2 arrays (each 1 GB large) to a third array.
With 2 x 1600 MHz memory channels (listed by Intel with 25.6 GB/s) the best real throughput is more in the 12-16 GB/s region. If you don't know how to tweak your access pattern, it is rather 8 GB/sec.
To add 2 double precision numbers, 3 x 64 bit memory transfers are necessary (2 reads, 1 write). If you divide 8 GB/sec by 24 Byte, the maximum flop/s your highly optimized LGA-1155 CPU can achive will not exceed with this simple program 333 Mflop/s.
Andy
Fortunately most programs aren't one giant stream benchmark. Most popular benchmarks these days are of real world programs that aren't architected to fit entirely in cache. But they also spend little of their time bandwidth limited and I think that's true for most programs people use - you can see this in most comparisons of programs running on dual vs quad memory channels.
So yeah, hiding latency of memory accesses is more critical.. but that's not only done by the caches but by the prefetch engines, OoO scheduling, and SMT.
How much an application's hot working set fits into the different levels of the cache hierarchy varies but you don't see this big 10x drop off between something that fit entirely in cache vs something that no longer does, because access within the working send tends to be very non-uniform.. You can have programs which touch a ton of memory but have it interspersed with spending a lot of time performing computations and control flow based on local variables clumped up well in L1 cache. Lots of programs have big data and code footprints but few of them drop below fairly high L1 hit rates.
So yeah, hiding latency of memory accesses is more critical.. but that's not only done by the caches but by the prefetch engines, OoO scheduling, and SMT.
How much an application's hot working set fits into the different levels of the cache hierarchy varies but you don't see this big 10x drop off between something that fit entirely in cache vs something that no longer does, because access within the working send tends to be very non-uniform.. You can have programs which touch a ton of memory but have it interspersed with spending a lot of time performing computations and control flow based on local variables clumped up well in L1 cache. Lots of programs have big data and code footprints but few of them drop below fairly high L1 hit rates.
Agree that not all programs are stream benchmarks. My comment was a response to the statement above that basically most perf increase comes from the "core" CPU.
BTW, many HPC systems turn SMT off - the ability of hiding latency in this class of apps is limited. Turning on SMT quite often leads to a reduced overall performance.
At the end, it is depended on the workload and profile of the apps, which component of the system is either a bottleneck or drives performance.
Being able to "read" benchmarks helps in this process 🙂
rgds,
Andy
BTW, many HPC systems turn SMT off - the ability of hiding latency in this class of apps is limited. Turning on SMT quite often leads to a reduced overall performance.
At the end, it is depended on the workload and profile of the apps, which component of the system is either a bottleneck or drives performance.
Being able to "read" benchmarks helps in this process 🙂
rgds,
Andy
Just for lulz, I disabled processor cache on the Core i5 2400S machine I have available and reran the benchmark scene using Povray 3.6. There's no change in render times between cache enabled and disabled. OTOH, the graphical interface is noticeably slower. Even command-line is a little slower.
FalseChristian
Diamond Member
My favourite chip was the Tualitan 1GHz Celeron. I got that puppy to 1500MHz. Stable as hell for almost 1 1/2 years. I figure my i5 2500K at 4.5GHz is at least 6 times faster.
What cache did you disable, and how did you do it? I'm surprised to hear there's an option to disable any level of cache on a Sandy Bridge.. L1 and L2 are deeply integrated with the CPU cores and L3 should be needed for coherency and is probably tightly coupled with the memory controller..
Personally I haven't seen options to disable L2 outside of uarchs where the L2 is technically optional - like with the first Celerons - or with Cortex-A8s.
The only way this makes sense to me if it's disabling all of L1 data, L2, and L3 cache. But the thought of disabled L2 or especially L1 not substantially diminishing performance of pretty much everything you run is unfathomable to me. I guess it's possible for just L3 to be disabled if the hardware forces a snoop to every core's L1 and L2..
Last edited:
Hi,
My first pc was with a 600Mhz Celeron Mendocino. Now, I don't seem to find anywhere but do you guys have any idea what was the SDRAM bandwidth on that platform?
Intel just announced that the new 9 series chipsets will support SATA express with 10 to 16 Gb/s transfer rates. I wonder if that's more than my RAM in the old days 🙂
My first pc was with a 600Mhz Celeron Mendocino. Now, I don't seem to find anywhere but do you guys have any idea what was the SDRAM bandwidth on that platform?
Intel just announced that the new 9 series chipsets will support SATA express with 10 to 16 Gb/s transfer rates. I wonder if that's more than my RAM in the old days 🙂
Easy enough. Set bit 30 of cr0. Processor cache is now no longer used. Some BIOSes allow this to be set in the BIOS. Otherwise it requires a kernel module and root access.
Last edited:
Your ram bandwidth on that platform was probably somewhere around 600-1000 MB/s. (guessing from my foggy memory)
Montsegur97
Member
Worst part about the pentium 75 we had...the whole system cost 3500$. I'm sure my parents hadn't shopped around properly, but still ridiculous.
Stock FSB for Mendocino Celerons was 66MHz, but I don't think there was a 600MHz one. It could have been Coppermine-128 (http://ark.intel.com/products/27191/Intel-Celeron-Processor-600-MHz-128K-Cache-66-MHz-FSB), still 66MHz FSB. Or it could have been overclocked, like a 400MHz Mendocino, that'd give 100MHz FSB.
66MHz = 528MB/s, 100MHz = 800MB/s
That sounds about right, for the time. Remember back then you'd spend $100 on a keyboard alone. Your hard-drive would run you $600 or $800. The PSU would be another $500.
We live in a golden age of inexpensive computing now.
Montsegur97
Member
Worst part, it couldn't even run NHL 96 and Mortal Kombat 3 properly. Though, I wonder if anything at the time could (with max settings). I'm sure the thing didn't have a dedicated GPU at the time. Then I remember a month later, pentium 90 being released and subsequently it seemed you were outdated every couple months.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 25K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 24K
-
-
