[cptskippy]

> I have no reason to believe that the M1's performance starts tanking if you run it for longer than a few seconds

This statement speaks volumes about your bias. You're immediately on the defensive and assuming we're attacking the M1 rather than the assumptions made in a test and it's methodology.

No one was implying that the M1's performance would tank. I specifically conjectured that perhaps x86, not M1, might have a penalty.

The original assertion made was that all x86 compiles were ~30% slower than the M1, but the benchmark was a ~20 compile. What happens if the compile is hours?

If the penalty is ~30% linear then a 60 minute compile on M1 is 80 minutes on x86. But if there's just a 10 second warmup penalty on x86 the compile time might only be 60 minutes + 10 seconds.

The truth is probably somewhere in between.

[coder543]

> But if there's just a 10 second warmup penalty on x86 the compile time might only be 60 minutes + 10 seconds.

But that doesn't make any sense, as I previously asserted. That's just not how any of this works. x86 is not suffering a "penalty". It doesn't need time to "warmup". I already discussed my views (based on actual real world experience) on all of this, but you conveniently bypassed those statements.

> This statement speaks volumes about your bias. You're immediately on the defensive and assuming we're attacking the M1 rather than the assumptions made in a test and it's methodology.

It really doesn't speak volumes. The default position I've seen is for people to assume that new technology is just a gimmick, and that results are only being cherry picked. And that's exactly what you just said you were assuming ("the truth is probably somewhere in between"), so I was right to reach that conclusion. No one here (that I've seen) is claiming the M1 is the unequivocal performance champion in all things, but it does really well in some use cases that impress me as a developer.

If it's really just about test methodology, you would just look up other tests, or run your own. Putting out completely unfounded statements like "what if there's a fixed 10 second ding on x86?" doesn't move the conversation forward when the hardware and results are so readily available. It's just a way of attempting to cast doubt on results. There's little need for speculation at this point, but you continue to speculate in defense of your previous comment without apparently having any hands on experience with M1.

[jfrunyon]

> But that doesn't make any sense, as I previously asserted.

Correct. It is an extreme used as an illustration to point out that you can not simply take the time savings on one compile and assume it will save the same percentage on a longer compile. I am not sure why that is so difficult for you to comprehend, particularly since cptskippy has specifically said "The truth is probably somewhere in between."

[cptskippy]

> But that doesn't make any sense, as I previously asserted.

Where did you assert that in our thread?

> It really doesn't speak volumes.

It does, you immediately assume someone is attacking the M1 because we question someone's assertion that the M1 is 30 something percent faster based on one small compilation benchmark.

[coder543]

> Where did you assert that in our thread?

https://news.ycombinator.com/item?id=27189764

"[...] in case you're implying that the other processors will "catch up" if they have longer to get up to speed... why would they? That makes no sense either. Longer compilations are faster on M1 too, relative to my Intel hexacore MBP, from what I've seen in the past. I mean, obviously, right? Why wouldn't they be? Intel's processors change frequencies in milliseconds... it doesn't take them minutes to warm up."

This is where I asserted that.

The only way there could be a "10 second penalty" is if the Intel processor just takes 10 seconds to warm up, and then it's on even footing after that point.

Intel processors takes milliseconds to change frequencies, so... clearly this is not a logical discussion point.

> It does, you immediately assume [...]

You actually misinterpreted my comment, possibly because you didn't read the rest of the paragraph that I copied above in this comment.

I didn't assume in that comment that anyone was "attacking M1" in the way you keep implying, based on the sentence fragment that you had cherry picked in your previous response. When I said that the M1 performance wouldn't tank, I clarified in that same paragraph that I meant this to be a relative measure compared to the Intel processor, since the Intel processor had its time to warm up and suddenly be super fast. If you read the whole paragraph, you should be able to see what I actually said.

If anything, I was defending Intel's Turbo Boost technology... which is the opposite of the conclusion you apparently jumped to.

[cptskippy]

> in case you're implying that the other processors will "catch up" if they have longer to get up to speed... why would they?

I never implied that x86 would catch up or even surpass the M1. I was suggesting that x86 might have some sort of delayed start but that actual compilation might occur at a similar pace to the M1.

The OP had a single data point based on a sub 60 second execution of a small project and extrapolated it out to a 30+ minute compilation of a larger project for comparison. He suggested that on a graph of Compile Time based on Project Size the divergence in performance might be linear.

I was merely suggesting there might be something else at play causing a delayed start of compilation on the x86 side. You came in and authoritative shut me down and then tried to suggest that we were being vague with our use of the term linear.

Imagine two runners that can keep similar pace but one always starts the race with his shoes untied and has to lace up as part of the race. Once he's laced up he can start running and will keep pace with the other runner, who has a head start, but will always be behind. That's what I was suggesting. In this analogy the length of the race is irrelevant.