Apple's follow-up to M1 chip goes into mass production for Mac

Re:Apple's follow-up to M1 chip goes into mass production fo... by coliveira on Tuesday April 27, 2021 @12:50PM (#26958432)

We don't even need to wait for that. Right now web developers are creating the new generation of web-based apps that will consume everything that M1 can give and more. In fact these apps already existed, they were just largely ignored because they're so power-hungry (just look at electron and similar stuff).

[ Parent | on HN ]

Re:Apple's follow-up to M1 chip goes into mass production fo... by mrweasel on Tuesday April 27, 2021 @01:05PM (#26958645)

Even worse: Developers will get an M-series Mac, write Electron apps that performs okay. They will then ship them as cross platform app, that will absolutely suck on any other platform.

[ Parent | on HN ]

Re:Apple's follow-up to M1 chip goes into mass production fo... by imtringued on Tuesday April 27, 2021 @02:55PM (#26959947)

Where is that inefficiency supposed to come from though? I mean there are four big inefficiencies that came with JS.

1. Garbage collection and minimum runtime

Garbage collection decreases memory efficiency, browsers need a certain minimum amount of resources to render a page, no matter how complicated leading to 500MB RAM text editors like Atom and worse once you open files. Similar problems plague Eclipse and IntelliJ which both often consume 1GB of RAM. The JVM often needs 150MB for an empty or perfectly optimized app.

2. Everything is an object with pointers

This is especially bad in Javascript where every object is basically a hashmap. This causes performance slowdowns because even something as simple as looking up a field is a pointer chase through several layers now. Raw numerical data may consume a lot of memory if you are not using typed arrays. Especially bad with ArrayList<Integer> in Java.

3. JIT

JIT compilers can only spend a certain amount of time on optimizations, which means JIT languages tend to either suffer from slow start up times or faster start up but less optimizations.

4. GUI complexity

Things like having animations and constantly recomputing layouts.

If you designed your processors for these things and made them fast at this, the only further source of slowdown is a lack of caring because you have already exhausted the unavoidable technical reasons. E.g. your processor is so fast, you write a naive algorithm that takes 5 seconds on the fastest computer available but then takes 20 seconds on an old computer.

[ Parent | on HN ]

Re:Apple's follow-up to M1 chip goes into mass production fo... by Klonoar on Tuesday April 27, 2021 @03:51PM (#26960634)

I don't think "animations" fits here. Well-implemented CSS animations are generally fine (though this is in and of itself a high skill to do well, I think). If you're still driving animations with pure JS, you probably need a refresher in modern web dev.

Diffing a VDOM might fit here, but that's not really GUI-specific - just a combination of your earlier points.

[ Parent | on HN ]

Re:Apple's follow-up to M1 chip goes into mass production fo... by zepto on Tuesday April 27, 2021 @03:38PM (#26960475)

> If you designed your processors for these things and made them fast at this

What does that look like?

There is a reason Apple doesn’t do #1 and #3 and is moving away from #2 in their own code.

They are just inefficient ways of doing things. Designing a processor to support an inefficient mechanism will still lose out to a processor which doesn’t have to.

[ Parent | on HN ]

Re:Apple's follow-up to M1 chip goes into mass production fo... by josho on Tuesday April 27, 2021 @03:35PM (#26960434)

I think the next layer is cross platform bridges.

Look at multi-platform products like ms office and how slow they run on a Mac. I suspect because there is a translation layer to bridge win32 calls to Mac equivalents. And that seems like it would be point 5 on your list.

[ Parent | on HN ]