ARM 서버를 10년째 개발해오고 있는 회사의 대표이자 개발자로서 정말 정말 재미있게 잘 보았습니다. 처음엔 다른 영상들처럼 또 CISC vs RISC 얘기로 애플 M1 칩을 분석하려나 했는데 뒤로 갈수록 그게 아니어서 무척 흥미롭게 잘 보았습니다. 애플 M1 칩은 ARM 의 SoC적인 특징으로 Unified Memory Architecture 라고 그들이 말한 메모리 공유 구조를 살펴보면 도움이 되어요. 정말 정말 재미있게 잘 보았습니다. 제가 유투브 영상에 댓글을 단 것도 처음이네요. ^^;;;
정말 마음에 드는 영상입니다. M1 프로세서가 출시되고 나오는 많은 영상들이 M1이 빠른 이유는 그저 Arm이고 RISC 때문이고 x86이 느린 이유는 CISC 때문이다 라는 영상이 매우 많이 나왔는데 대부분 현대에 들어선 서로 장점을 흡수해서 x86 프로세서도 RISC 처럼 돌아간다는걸 빼먹어서 답답함이 있었거든요. 진짜 빠른 이유는 die 크기가 더 큰 만큼 더 많은 트랜지스터가 들어가서 뉴럴엔진이나 미디어 엔진이 들어가고 메모리가 내부에 들어있어서 전송 지연도 느리고 캐시도 많고 gpu와 메모리를 다이렉트로 공유한다는 점 등 때문인데 말이죠... m1 max 다이 사이즈와 트랜지스터 수를 비교하면 x86 서버용 cpu에 맞먹는데 말입니다...
다른것 보다는 애플이 다른회사의 영향에서 벗어나는것을 선호해서 ARM으로 가는것 같습니다. 인텔보다는 ARM이 개발의 자유도는 훨씬 좋은걸로 알고있습니다. 게다가 20세기때 윈텔에게 개발린 복수할 기회도 계속 보고 있다가 이번에 시원하게 한방먹이게 되었구요. 차후에는 ARM 그늘에서도 벗어날려고 노력하게 될것 같습니다. 애플이 원래 혼자서 다해먹거나 자신들의 아래에서 있는걸 좋아하지 동등하게 뭘 하는걸 싫어하는 회사라서...
ARM 자체가 모바일 시장에 유리한 것도 크죠.. 얘네들은 토끼를 몇 마리나 잡는건지 모르겠네요 ㅋㅋ 본인들도 ARM 전환 계획 잡고 개 꿀 외쳤을듯. 마소가 서피스 RT 만든다고 큰 돈 그대로 때려박고 상심해서 삽질하던 차에 애플이 격차를 너무 벌렸네요. 팀 쿡이 동성애자였던 거 뻥이라고 리턴아웃하지 않는 이상 애플이 10년간은 독주할 것 같음..
모바일과의 통일성 유지도 큰 것 같은데요. 맥과 아이폰 아이패드가 동일 코드로 완벽하게 호환되지는 않겠지만 그래도 동일 프로세스를 적용하게 된다면 그래도 인텔칩보다야 크게 작용하겠죠. 일단 인텔칩이야 전혀 건드릴수가 없으니까요. 그리고 ARM에서 벗어날지는 모르겠지만 현재 ARM이 제조사에 간섭을 하는 회사가 아니라서요. 요금만 지불하면 자기네 설계도 가져다 북을 치던 장을 지지던 전혀 간섭이 없으니 굳이 단독개발로 갈까요? ARM보다 좋은 새로운 프로세서가 등장하면 모를까...
16~19년도쯤의 상황을 되돌아보면 저는 대략 세가지 정도 요인이 눈에 띄네요. 1. 인텔 프로세서의 성능향상폭이 오랫동안 기대에 못미쳤고, 이때문에 8년전 10년전 맥을 그대로 쓴다는 얘기가 흔할 정도로 맥 교체 수요가 안생김. 2. 팬리스 성애자 애플이 아이패드 노하우도 있겠다 인텔믿고 12인치 뉴맥북으로 오랜만에 노쿨링팬 시도했다가, 역시나 이번에도 발열과 쓰로틀링때문에 욕먹음. 3. 예전에는 윈도우와의 병행사용을 위한 호환성이 중요했지만, 이제는 아이패드/아이폰용 앱과의 호환성이 생기는게 윈도우 호환성 유지보다 더 메리트가 커짐.
예전엔 cisc는 한 클럭만에 1개의 instruction을 수하하지 못핬고 risk는 한 클럭에 모든 instruction 실행이 가능, 하지만 80계열이 프로세서 시장을 선점했고 개발툴이 많았음. 그에 반해 고성능 risk는 웍스테이션용으로 사용(대중에게 멀어짐, 80계열은 친 사용자환경과 대중화를 중시함) 쭈욱 80계열이 장악하다가 모바일쪽이 파이가 커짐(모바일은 고효율을 중시함) 파이가 너무 커지다보니 고성능으로 발전함 이제 맞다이 뜰만하니 애플이 pc로 만들어 버렸는데 대박침
Can you please make a video why so many AAA games companies uses Unreal Engine game engine instead of Unity Engine? and if you have more ideas about game development it will good, I really like this topic 😄
I guess it will be performance issue, unreal is c++ and unity is c# and c# is slow than c++. Of course I don't know about both but i guess unity is mean to crossplatform, not performance
USING language different C++ more effective about complie. C# have more complie processes go to assembly. (C# is released later than c++ and has more compilation processes.) (if something is wrong, tell me about that!)
이 영상이 필요하다고 말씀드린 보람이 있네요. 컴파일러와 어셈블러 때문이라고 알고는 있었지만 코드를 직접 보여주면서 비교해주니 확실하게 이해가 되네요. CISC, RISC 설명도 도움 많이 되었어요. 정리하면 개발자들의 요구에 따라 트랜지스터의 구조(CISC, RISC)와 명령어 셋(ISA)이 다르게 설계되어서 전기적 특성과 사용하는 해석기(어셈블러, 컴파일러)도 차이가 난다는 거군요. 그러면 맥의 로제타는 CISC의 어셈블리 코드(ISA)를 애플용 RISC의 어셈블리 코드로 바꿔주는 변환기라고 추측할 수 있겠네요?
인텔은 공무원화 된지 10년이 넘어서 이젠 거의 발전이 없는 조직이죠 앞으로 cpu 는 arm 쪽이 대부분 다 장악할 것으로 보고 있습니다. 특히나 클라우드기반 메타버스 사회가 되면 특정 기능만 잘하는 클라우드 시스템에 최적화에 좋은 ARM으로 최적화된 cpu만 생산하면 되기 때문이죠
니꼬샘이 영상에서 이야기 했듯이, RISC 계열의 기술은 펜티엄시절부터 인텔에서 서서히 적용하기 시작했습니다.. 확실히 확인 된 사실은 아니고, 아직도 말이 많기는 하지만. ISA 밑의 opcode 영역에서는 인텔 프로세서들이 굉장히 RISC 처럼 작동한다는 설도 있고..
인텔 CPU도 어느 분 말씀처럼 내부적으로는 ARM과 같은 RISC 방식으로 구현되어 있어요. 파이프라인이라는 동시 수행 효율을 내기 위해서는 어쩔 수 없거든요. 그리고 이게 펜티엄 후속 버전인 펜티엄프로(무려 1995년) 때부터 적용된 것이랍니다. CPU 외부에서 볼 때는 (소프트웨어) 기존 CISC 명령어를 받아주고 그걸 내부에서 처리할 때는 RISC 형태로 잘게 나눈 뒤 실행 효율을 올리는데 그 때문에 CPU 내부에 이런 변환을 담당하는 디코더 로직이 엄청나게 들어갔습니다. 그래서 칩 구조가 복잡하고 발열도 훨씬 많아요. 반면 이런 게 처음부터 없는 ARM은 훨씬 단순하죠. 그래서 캐시나 심지어 메모리까지 더 집어넣을 수 있고.. ^^
omg you explained all these concepts and applied it to real life examples that my prof couldn't even explain in an hour. Thank you sooooo much!!!! You're such a great teacher!!
Do note that there are several subtly incorrect statements in here. That's part of the "like I'm 5" qualifier, made to simplify the information so it's a tiny lie that would be easier to understand if it were true, and it's close enough to the truth that you aren't terribly misled. Your professor likely explains this more accurately. For instance, a compiler builds to machine code, not assembly code. There would be no purpose in that intermediary step, however some compilers (such as GCC) have an option to emit assembly _instead_ of machine code, but that is used rarely and only for low-level debugging or codegen introspection. Personally, I never emit the assembly, because the machine code can be disassembled by my debuggers such as GDB and Rizin, and that code is more useful because I can step through it in Emacs and see the registers update, or step backwards in rr (attached to GDB) or Rizin (only when it's _not_ attached to GDB). If I compile with debug symbols, then the ELF header contains all the DWARF and GNU-extensions that my debuggers need to tell me everything I care about.
@@Cons-Cat thanks for the heads-up! I’ve only seen this comment now. There are still many concepts that I don’t know but after taking the class with my prof on computer architecture, I understand what you mean with how high level language gets translated to assembly, then to machine code. From what I’ve learned so far, compilers create object files which then help in gathering the assembly code into an executable file in machine code. I’m not sure how this info fits into what you’ve said about emitting assembly but thanks for bringing these up. I’ll search about them :)
그런데 이런 것들은 대학교에서 전공한 분들은 학교에서 배우지 않나요? 학교 졸업한지 20년 되었고, 학교 다닐떄 공부 잘 하던 학생은 아니었지만, computer organization, computer architecture, programming language, compiler 클래스에서 다 언급 되었던 이야기들 같은데.... 물론 100% 이해를 했던 것은 아니었지만.. 대략 개념이나 용어들은 익숙한 내용인데..
If you are just memorizing the information in this video, then you will have a limited understanding of how processors work. If you focus on how and why processors work the way they do, which requires further study, you will have a much better understanding and then you can use your understanding to come up with creative solutions to problems. If all you do is memorize, you might be able to get a good grade on a test, but you will have learned very little.
One thing you didn’t mention and as someone who has watched the rise of RISC from its very beginning, is something I think is quite important… Execution speed! CISC processor instructions often require multiple clock cycles to execute, with more complex instructions requiring multiple clock cycles and multiple registers to execute. RISC on the other hand has design points that allow the majority of its instructions to run in a single clock cycle, which was always the key advantage of RISC architectures, even today. Going back to your Power Of Three example, on CISC this may require several clock cycles to run, let’s say 4 per step point, the steps would be 3 (value x value c value) so that’s 12 clock cycles. While there may be 6 instructions on the RISC platform, each operates in a single clock cycle so at the same clock speed for each architecture, the RISC processor executes the same process in half the tine. Carrying out the same process on CISC using individual instructions could take longer still! My first experience of RISC processing was with transputers, but soon used the ARM chip in the Acorn Archimedes and thanks to Acorn and Apple, along with LSI helping Acorn spin off the processor into a licensing model in the early 90’s, we have a ubiquitous yet diversified platform powering much of our world today
If i understand right, that explains why Arm processors don't have high clock frequencies and yet still execute instructions faster than x86 with higher clock speed
@@softwarearena7592 correct, while at school I remember the 8MH Archimedes outpacing every 286 PC still available and all but the top end 386 and early 486 systems. The Acorn A7000+ that I had ran at 25MHz and could give the low end PC’s of the time a run for their money with better file management, true 32 bit system architecture throughout, something Windows users outside of business (with Windows NT) wouldn’t get until Windows XP in 2001.
IBM에서 인텔로 갈아탔을때와 동일하지 않을까? x86이 점점 Power 계열의 성능을 따라잡았고 발열도 훨신 적고. Power계열 발열때문에 G5 수냉쿨러는 진짜 최악이었음. 그리고 당시 Power 계열 프로그램의 x86 OSX 하위 호환은 얼마 가지 않아 끊어 버린 것도 소비자로부터 욕먹었고.