The reason none of the reviewers are talking about how the CPU performs thermally is that Intel didn't allow them to. See page one of the Anandtech review for instance: https://www.anandtech.com/show/14664/testing-intel-ice-lake-... Not that they could have got terribly meaningful results anyway, since this was a fairly large and thermally unconstrained test system with the fan locked at 100%. (Since the kinds of systems this CPU would be used in are very thermally limited, this means the performance figures may not be terribly representative of the real world either.)

Huh, I hoped these test-NDA were a thing of the past again. But yeah, tests would probably not be conclusive in that case.

Still the topic that would interest me most compared to CPU performance.

Not when you need to make up some lost momentum and the competition is already running with it.

Intel keeps doing these paper launches and early announcements meant to keep them a little in the spotlight. They're not having a good time for a while now. Some websites take it with a gran of salt, some still don't, even after being repeatedly used to tout a nonexistent horn.

When you do something, the cpu works at _full_ speed for a given duration, which is shown as %/time used. If you make a processor half as fast, all CPU tasks will be performed two times slower.

> Spectre probably knocked of Intels performance advantage, but is CPU performance really our current bottleneck?

this is what my computers have to say about that :

https://i.imgur.com/2MGzz58.png

https://i.imgur.com/h2d8FO8.png

Links are broken

No, they aren't. (That said, they're completely uninformative and I have no idea what the heck these tiny unlabeled ASCII graphs are trying to convey. The ability to draw a lot of | characters quickly, perhaps?)

Look up "htop output" on Google image search.

I was expecting a before & after set of graphs.

it's my cpu usage when building stuff - 100% on all of my cores

Quite a sight to see. I'm surprised that the build process is able to efficiently use up all of those cores. Plus I see you've got 64 GB memory, quite a beast of a machine. Care to share some more hardware specs and some details about the build process? (Compiler, language, purpose?)

sure - cpu is an i7 6900k so 8 core / 16 threads, overclocked at 4ghz. The software (https://ossia.io) is in C++17 built with cmake / ninja / clang / lld so an incremental rebuild is between 1 and 5 seconds for most files (which is still waaay too slow for quick edits), but a full build is 5-7 minutes depending on the optimization options, debug mode, LTO, etc.

Also, most ram here is not taken by the build process but by firefox tabs & a windows VM.

Hugely interesting bit of nerd porn, thanks for the reply.

Why would you say that the lower frequency would be better for thermals and power consumption? It would only be better than the same chip at a higher clock rate. If Intel could increase the clock and maintain the power consumption that's what they would do. From that it follows that these chips consume more power at a lower clock rate.

> Why would you say that the lower frequency would be better for thermals and power consumption?

Because transistors have a capacitance that one has to drive, higher frequency requires more voltage and more voltage means bigger leakage currents which means more heat and power consumption.

Good question, that was just an assumption. I thought that the improved manufacturing process would limit power consumption and was the reason for the decreased clock. But yeah, there could be completely different reasons for that.

That's a bit of a silly statement. And misogynist to boot.

Hardware is cheap. Programmers are not. It makes much more economic sense to have programmers "use layers upon layers" and buy extra CPU, than to have a couple of x86 assembly gurus hand craft every opcode of your application.

And force your users to buy extra CPU*

Development time may be more expensive than hardware if you're developing internal software for a small-ish company, or something extremely niche, but less so when the bloat saves some time for your relatively small team in exchange for bringing massive pain to the thousands/millions of your users.

I personally refuse to use "bloated" software even when there's no alternative, but it's a drop in the ocean. Some of the folks I know can't take the same stance simply because they don't know that a text messenger doesn't have to eat half of your machine resources and slurp the battery to zero in half an hour of usage. For them it's just something you have to deal with.

Had to look that term up. I have nothing against women. The opposite. I just don’t like layers upon layer of fake to conceal problems.

Same with programmers.

It doesn’t make sense to make 1billion people buy more hardware bc a small bunch of programmers.

It has nothing to do with handcrafting asm. All the virtualization, virtual machines own little patchy frameworks which are unnecessary, virtual dom, the actual dom. Just to show a some text or a button on the screen which doesn’t adhere the OS Interface guidelines and probably doesn’t support screen readers, color scenes, font changes, dpi changes, proper behavior, keyboard navigation, scriptability.

Yes, I like things and people lean.

> Hardware is cheap. Programmers are not.

I hate this line of reasoning. Yes it is true, as long as you keep things reasonable. But many use this principle to go beyond the reasonable.

Slack probably has cost much more in electricity alone than it would have taken to build a more efficient client.

Maybe. But I just program cake face for myself!

But seriously, if programmers hadn't several software levels to rely upon, a simple software tool would cost millions and would require an army of engineers or a few years to be completed.

Programmed a scroll bar for an UI toolkit once. That isn't as trivial as it seems and takes a while. A scrollbar...

I've never implemented one so I'm sure it's more complex than what it looks like.

So you piqued my curiosity. What are some examples of those non-trivial things?

It has been a quite while... determining the length of the content you are scrolling and the size of your viewport was a challenge as well that catching every event that could change the position of the viewport or generally handling input.

It was implemented in C for a small display for debugging controller for a µC. It did take quite even without any dynamic content for something we take for granted. And in the end it still was pretty clunky.

I believe that browsers still disallow customizing scrollbars and there are countless examples of people having build their own scrollbars to replace them. Many of those are quite wonky, so that calms me down at least.

Interesting.

I guess it's one of those things we take for granted now and thus you think that it can't be that hard to create... and then you try to do so and you realize how complex some things really are.

Thanks for the details!

Not all abstractions cost anything, they're simply useful. In addition IDEs, compilers and other parts of the toolchain pump up the output quality significantly compared to what would otherwise be available at a given time.

Programming doesen't exist in a vacuum. It has real business constraints, and you simply cannot make a perfect program. You must make the right compromises in order to be succesfull.