411–420 of 427 posts
Earlier quoted context omitted.
I’d like to point out that compiling stuff is usually disk/io intensive. Could this not just be that the Apple machine has a faster hard drive/memory?
It doesn't. It has the same 4 lanes, PCIe 3.0 flash as everyone else.
Earlier quoted context omitted.
Strange. With the exception of electron apps (which are slow everywhere), I've found my M1 mini to be extremely responsive. Much moreso than my 16" mpb.
VS Code launches instantly on my i7-4770 under Linux with XFCE. Same under Windows. So do Slack and Spotify... That's an 8 year old CPU! If you're having issues, the problem lies elsewhere not with Electron.
I don't have any measurements, and I'm not really going to take any. It's just always felt slow. So I'll admit I should've perhaps been less prescriptive.
Earlier quoted context omitted.
I don't know, I feel other laptops at the same price point as Apple Macbooks do this too, sometimes even better. I bought a HP 8530w in 2009 or so and it still works. Replacing the DVD drive for a SSD required just a common Philips screwdriver and battery replacements are sold by HP themselves or many others.
The point is that with mid-2010s apple laptops, >5 year lifespans are the norm. With the majority of other, even comparably priced laptops, that is the exception. There are other laptops that are similar or superior build quality to those from Apple (N.B. - older MacBooks, not the newer ones) but those are also easy to spot. They’ll usually be ThinkPads or some XPS models from dell.
Earlier quoted context omitted.
I've worked that way for 10 years. My current desktop is a 5 year old Intel i3 NUC with a paltry 8G of memory. Granted, it uses all that memory (and a bit more) for a browser and slack, and the fan spins up any time a video plays. But usually it's silent, can drive a 4k monitor, and most of the time I'm just using mosh and a terminal, which require nearly nothing. OTOH, the machine that I'm connecting to has 32c/64t,…
> the machine that I'm connecting to has 32c/64t, half a terabyte of RAM Ok I'll bite, what do you do? Do you think halving the number of cores / RAM would impact your productivity?
Earlier quoted context omitted.
> 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…
> 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 st…
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.
Earlier quoted context omitted.
> 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 st…
> 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.
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.
Earlier quoted context omitted.
Wow. The fact that my Sandy Bridge laptop from 2011 does it in only 1:41 is pretty indicative of how badly processor improvements stalled out last decade. My processor (like yours, 4c8t): https://ark.intel.com/content/www/us/en/ark/products/52219/i...
You compare TDP 45W CPU vs 15W. I think this is great improvement. (But latter one is also 25W cTDP and turbo boost provides more power, many factors depends on how the laptop implemented)
Earlier quoted context omitted.
> 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.
> 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 proces…
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.
Question for the peanut gallery: In a -nix OS system, let's say single-threaded process is running on core 0. It makes a syscall. Does core 0 have to context-switch in order to handle the syscall, or could the kernel code run on core 1? This would allow a process to run longer without context switching and cache dumping, which would improve performance (as well as potentially security). Corollary question: could one…
If the system call is being handled by core 1, what does core 0 do? It must somehow wait for the core 1 system call to return. I'm not sure the waste created by waiting is outweighed by cache benefits.
Earlier quoted context omitted.
I think it did, and the touch bar was a close second. Thankfully, whoever was in charge of those decisions seems to have lost decision-making power and Apple has walked back both.
the touch bar still ships with every current-gen MBP though; the Air never had one