Performance comparison: 15 W ULV dual-core vs. 45 W HQ quad-core CPU

This test was fairly straightforward: The aforementioned 100 MB PDF file from Princeton's website was opened using Adobe Reader and then scrolled through using the mouse wheel. After an initial period of the base scroll-wheel action, the wheel was clicked and held while dragged, for a faster seek speed. Finally, we then rapidly dragging the scroll bar at the right from the top to near the bottom. No lag or issues were present while performing this action on either system, and with a maximum total CPU utilization of approximately 15% on the quad-core and 40% on the dual-core, most any computer made in the last few years should get through such a task with ease.

Once again, the spreadsheet test is fairly straightforward. The CPU hit is negligible on the quad-core and the dual-core still had plenty of breathing room. Similarly to the PDF test, any PC made in the last 5 years or so should have little issue with using spreadsheets (or even spreadsheets and PDFs together).

We note that starting the browser does not usually hold 100% utilization very long if at all, but should one have multiple windows with multiple tabs open, closing one window and re-opening that window will force a processor cleanly to 100% — unlike restoring an entire browsing session. This is not pictured here, but it's interesting to note. Even with a powerful CPU, such an act will cause noticeable issues with any open program heavily dependent on the processor, such as a video game, where even on i7-7700Ks slowdowns to extremely low FPS ranges, garbled audio (ONLY from the game; rest of the system was fine), etc has been witnessed. The longer the CPU is pegged at max, the longer the program in question will suffer, of course.

Unfortunately, we could not get this same test running properly for both notebooks. For the Clevo, we took the installer data for multiple The Sims 3 expansions (each expansion in its own folder) and used 7zip to compress them all into one massive archive. The combined filesize of the folders was an impressive 17.3GB. As the test progressed, it was noted that unlike in other tests, the CPU killed its own boost clock down to 2.6 GHz. There were no reported limitations using Limit Reasons with Throttlestop, indicating that while the CPU was not boosting, it was not "throttling" either. As it turns out, this was tied to the "Balanced" power plan in Windows; despite the plan manually configured such that the speed be minimum 5% and maximum 100%, turbo boost was still revoked while it was active in this test (but not any prior tests). Copying every setting in the "Balanced" power plan into the "High performance" power plan (including 5% minimum and 100% maximum processor states) and then enabling the High Performance plan completely negated the loss of turbo boost for the processor.

While it sounds like a nonsensical problem (and fix), this is actually not a rare occurrence: it is present all the way up until Windows 10 and can even affect desktop processors. At some point, this issue can "go away" as if it never was present in the first place, but the "High Performance" power plan must be used for some time before it does. Waiting for this normalization was not attempted on the notebook in question, and so the results reflect the lower clocks. We recommend that if you are noticing your notebook losing turbo boost when performing certain heavier-load tasks, switching to (and editing to suit — especially if wishing to use the notebook on battery) the High Performance Windows power plan is recommended. For this reason, the picture taken was made while compressing (the compression easily lasted over half an hour) but after figuring out why turbo boost was not active, and therefore the graph did not capture the resting state prior to using the program. It is our opinion, however, that the resting state comparison was not needed due to the extremely high load on the processor.

On the Toshiba, however, we began using High Performance, so there was no issue with reduced clockspeeds during the testing. The test was not the same, however: we instead tested a folder full of multiple benchmark software installers (such as PCMark 7), and the results were surprisingly easy on the processor. What's more, performance seemed rather varied. Unlike on the Clevo unit which kept near maximum processor usage for the entire compression run (30 minutes or so), as the compression test continued on the Toshiba, it was clear that processor loads seemed to rise and fall depending on what was being compressed — meaning that the data from the Clevo unit is not indicative of all tests, but rather that each zip operation is unique depending on what is being compressed.

In light of the above revelation, one factor was failed to be examined: Windows 10 versus Windows 7. To test whether the above hypothesis is true — that the workload is what matters and that the operating system has little effect on compression performance, we used a second notebook to zip the same workload as the N155RF. This notebook is a Clevo P870DM3 running Windows 10. By comparison, this notebook has an overkill i7-7700K desktop processor in it, running at 4.4GHz, meaning a great excess of power is available compared to either test unit — but even so, this processor was also pegged almost entirely at 100% for the duration of the test, indicating that the OS neither boosts nor hinders compression in any meaningful way. 

Another fairly straightforward test. Unzipping data seems to be somewhat consistent in terms of CPU utilization regardless of what is being unzipped. The per-core utilization of the quad-core versus the dual-core indicates that almost regardless of what's being decompressed the load is approximately the same; at this point it is likely that RAM would have a larger impact. For the sake of being certain, unzipping was done from HDD to HDD, from HDD to SSD, and from SSD to SSD on the Clevo (the Toshiba does not have a HDD and can only do SSD to SSD). The extraction speed did not change, and neither did the average CPU load. The above picture for the Clevo unit is from HDD to HDD.

The Toshiba had high utilization at some points, but in general was able to handle the workload well. However, if decompression is what one wishes for, this may be in the realm where a quad-core CPU is going to help more.

Three YouTube video tests were conducted: playback of 720p 30fps, 4K 30fps, and 4K 60fps video. All tests were completed using Google Chrome with hardware acceleration enabled in the browser settings.

The 720p test was relatively easy to complete; most any CPU made in the last 6 years could comfortably get away with up to 1080p 60fps YouTube video watching based on this data, and the data for the 4K 30fps video suggests that it should be easily handled as well: while 4K 30fps was more difficult to complete, it should be simple enough for any quad-core CPU. There was a time in the past when watching 4K 30fps youtube on a high-end CPU would cause 100% utilization, but we are nearly a decade on from that era. This is a testament to how much faster CPUs have become (even through incremental updates).

Of interest to note — both here and with all prior tests — is that when CPU load is not sufficiently high, Windows tends to favor only one thread per CPU core and will use up to four cores easily until more load is required. On a dual-core CPU with hyperthreading (like the Toshiba's i7-7600U), all four threads are loaded much more easily.

The problem test is 4K 60fps. As hinted at in the 4K 30fps result, it appears that Windows 7 (and 8.1) cannot use GPU acceleration for videos in google chrome and other browsers (as is possible in Windows 10). An incomplete list of devices with VP9 decoding support can be found here (though not listed, the GTX 965M in the test unit is indeed GM206, and thus is capable, proving an OS-level limitation for VP9 decoding).

For this reason, the 4K 60fps video test, while not actually "maxing out" the processor utilization but instead hovering at very high usage, exhibited multiple stutters and freezes in the video and audio. The reason the CPU is not pegged consistently at 100% despite the load is because frame data is actually being dropped or discarded instead of being rendered, which causes the stutters. It is similar to livestreaming with very high compression — when the CPU cannot properly encode enough frames, it will spike close to 100% then drop utilization as it skips frames to encode as it cannot encode them on time.

Windows 7 and 8.1's lack of encoding support is important to mention, because while most users will be using windows 10 with newer machines, many work-based and enterprise laptops use Windows 7, even though Intel Kaby Lake and AMD Ryzen processors and onward are not "officially" supported on that operating system.

On the other hand, the Toshiba notebook has little issue completing any of these tests. The load from buffering is high on 4K 60fps, but not nearly enough to hinder the CPU or the playback functionality of the video. This is the largest advantage to the new operating system over the old ones, and is what Apple has been doing for years with OS X and Mac OS using their first party programs (like Safari). The CPU load is somewhat high considering rendering the video takes almost no processing power, but the dual-core still succeeds with little issue.

Since the Toshiba proved that once using Windows 10 the load on the processor is much reduced, it's now known that hardware acceleration works wonders when it is enabled. But what about gaming notebooks that use Gsync, which have their iGPUs disabled? Nvidia Pascal GPUs and some Maxwell GPUs are capable of hardware acceleration on Windows 10, so the Clevo P870DM3 from earlier was also used to test. It is to be noted that, while this notebook does have a far stronger CPU, the utilization percentage is what is important. In fact, the only added load on the system in this case is the one from the video buffering like with the Toshiba test. Buffering videos on YouTube adds CPU usage, and that is almost the entire extra load that is observed during the course of the video. This is what one can expect from all YouTube videos from any system that has hardware decoding enabled. It IS possible to turn hardware decoding off (and many users do, because it can cause bugs with video playback in many cases — especially on 60fps content), so both hardware acceleration on/off tests are useful to check.