14P by xguru 2020-11-29 | favorite | 댓글 5개

1. 흑마법처럼 보이는 애플의 인텔코드 실행 속도는 기본적으로 Arm과 Intel 아키텍쳐의 결합
2. 두 CPU는 기본적으로 "메모리 오더링"이 달라서 에뮬레이션 속도가 느린데, 애플이 한 해결책은 인텔의 방식도 넣어 버린 것. x86코드를 실행할때는 인텔의 메모리 오더링을 따르게 만듬
3. 자바스크립트 최적화된 명령어들을 추가하고, L1캐쉬를 두배로 함으로써 웹브라우징을 할때 더 빠르고 배터리가 오래가게 만듬
4. 인텔 맥북에어의 듀얼코어는 빠를때는 3.8Ghz 이고, 느린모드에서는 1.2Ghz로 동작해서 전력을 아꼈지만, 인텔은 다운클럭에서 실행되도록 설계한게 아님.
애플은 성능과 효율용 프로세서를 각각 4개씩 넣어서 최적화. 저전력모드에서는 성능 프로세서 4개를 끄고 효율 프로세서 만으로 동작.
컴파일 같은 작업을 할때는 4개의 프로세서 전부를 활용해서 정말 빠름.
5. 인텔이 무어의 법칙에서 3년 뒤쳐짐. 애플 실리콘은 TSMC의 최신 5나노 공정을 사용하는데, 인텔은 10나노/7나노 공정을 사용하고, 심지어 많은 인텔 제품들은 더 오래된 14/10나노 공정을 사용함 .
6. Swift 언어는 안드로이드의 "가비지 콜렉션" 대신, "레퍼런스 카운팅"을 사용함. 애플은 레퍼런스 카운팅 속도를 두배로 올리기위해 CPU에 뭔가를 해뒀음.

왜 ARM칩엔 JavaScript 이름이 붙은 명령어가 있나요? https://news.hada.io/topic?id=3057

레퍼런스 카운팅이 가비지 콜렉션의 기본 인데... 뭔 소린지... 갑자기 신뢰도가 확...

관련해서 이런 얘기가 있네요.
https://twitter.com/catfish_man/status/1326238434235568128?s=21

단순 NSObject 를 Retain/Release 하는 속도 자체가 5배 빠르다고.
레퍼런스 카운팅하는 명령 자체도 메모리 오더링 구조 차이때문에, 더 빠르게 동작한다는 듯

Java에서는 대개 Reference Counting이 아니라 Mark-and-Sweep처럼 다른 스타일의 가비지 콜렉션을 쓰니까요.

어? 했는데.. 가비지콜렉션도 그럼 그만큼 빠르겠지라고 생각해주면 되것죠.. ㅋㅋ