context switching 시 쓰레드가 프로세스보다 빠른 이유에 대해
글쓴이: 익명 사용자 / 작성시간: 목, 2018/08/09 - 6:05오후
쓰레드가 context-switching 시 덜 부담되는 이유를 모르겠습니다.
빠른 이유로 생각하기 쉬운 것들을 나열해보자면
1. 쓰레드는 프로세스와 다르게 스택 외 메모리 영역을 공유한다.
-> 그러나 context switching 발생 시 커널 스택에 저장하는 것은 레지스터 값들이라고 생각하기 때문에, 즉 쓰레드도 독립된 실행흐름을 갖기 때문에 프로세스와 달리 생략되는 부분이 없다고 느껴집니다.
2. 캐시 메모리를 효과적으로 사용할 수 있기에
-> cache affinity를 최적화하기 위한 것은 쓰레드/프로세스가 아닌 서비스를 받았던 프로세서에게 다시 서비스를 받느냐가 중요하다고 생각해서 이또한 이유가 될 수 없다고 생각합니다.
좀 더 극명하게 빠르기의 차를 보여주는 이유를 알고 싶습니다.
틀린 부분은 지적해주시고 답변 부탁드립니다!
Forums:
참고해보세요.
검색한 내용을 파일로 첨부합니다.
1. 스레드는 메모리를 공유하며. 힙 메모리 공유한다는거 같네요.
2. 스레드 스케쥴링 큐'가 있다고 합니다. 소프트웨어 스케쥴링?을 한다는거 같습니다.
- (윈도우의 경우) 레지스트리에서 L2 캐시 크기를 변경하여도. 별 차이는 없었습니다.
- UI 를 스레드로 분리하면. 조작이 좀 더 안정화 됩니다.
- 크리티컬 섹션'을. 사용하시면. 멈춤 현상이 줄어듭니다.
- 이벤트와 if() 조건문. Sleep(1) 등을 사용하기도 합니다.
- GPGPU 100배 > AMP > SSE > MMX > PPL > 정적 배열 > 동적 배열 > 성능이 좋습니다.
- 현재 웹브라우저에서 SSE 를 지원하는 브라우저는 Fire FoxNightly 로 알고 있습니다.
- AVX (Hyper-V) 지원 CPU 성능이 좋다고 합니다.
마영전 게임을 할때. 빠른 컴퓨터가 방장이면. 클라이언트도 빨라집니다.
- vGPU 를 지원하는 경우. 메모리 공유도 된다고 합니다.
- Ultra DMA6 를 지원해서인지. VirtualBox 에서 하드 성능 점수가. 200 MB 에서 2000 MB 이 되었습니다. 실제 속도는 아닌것 같습니다. (PV Driver도 있다고 합니다.)
- (윈도우의 경우) 프로세스가 스레드 보다 성능이 좋습니다.
프로세스 > 스레드 > 윈도우 프로시저 (메시지 큐의 제한이 있음)
- (윈도우의 경우) IPC 역시 메시지 큐의 제한이 있음
- 오버클락시 하드웨어 파손. 주의! 전문가에 도움을 받으세요.
GPU Flops Clock 320MHz Memory Clock 260MHz 오버클락 20% 향상 > CPU Clock 320MHz 오버클락 20% 향상 > 전원 (최고 성능 모드) 10% 향상 > 프로세스 우선 순위 5% 향상
- VPU DXVA2 비디오 렌더링 50 배 향상
- 윈도우10 장치로 캐스트 사용시 CPU 점유율 1% 사용
- (윈도우의 경우) 전원 설정 / 시간 설정 / HPET / bcdedit.exe / powercfg.exe 등은 일부 영향을 주었습니다.
프로그램은 빠른것보다. 멈추지만 않으면. 일단은. 잘 될겁니다. ㅇ_ㅇ;;
- 0 1 2 텍스트 문자 파일을. 7z LZMA 알고리즘으로 압축시. 1000 배 이상 압축.
- CPU 확장으로 25개 연결 가능 : 피톤 오픈소스
- GPU 확장 연결. 여러개 연결 가능 (전기세 전력소비율 확인 필요)
- Docker Container (Hyper-V) 사용시 네트워크 프로세스 실행
- 웹에서 실행 가능 : PNaCl NaCl 스마트 TV / emscript-qt / asm.js 웹에서 실행 가능
- (윈도우의 경우) 가상 메모리를 적용해 주면 메모리 문제가 적어집니다.
- CPU / Sprite / 3D FPS 가 각각 있습니다.
- (윈도우의 경우) 해상도 / 색상 / 장치 드라이버 등에 영향을 받기도 합니다.
- DPC Latency 반응 속도? 등에 영향을 받기도 합니다.
----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.
매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.
각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com
여러 가지
저는 이쪽 전문가는 아닌데요. 여러 가지 생각해 볼 수 있을 것 같습니다. 큰 차이 중 하나는 프로세스는 각 프로세스마다 address space를 따로 가지고 있지만, 쓰레드끼리는 공유하죠. 페이지 테이블을 쓰레드끼리는 공유하지만 프로세스 끼리는 공유하지 않게 됩니다. 보통 페이지 테이블은 메모리 상에 있고 TLB에 캐슁이 되는데, 프로세스 스위칭의 경우 TLB 캐쉬도 날아가겠고, 컨텍스트 스위칭 시에 페이지 테이블도 필요하다면 저장을 해야 되겠죠. 캐쉬도 쓰레드와는 달리 프로세스의 경우 invalidate되는 경우가 제법 있을 것 같구요.
초기에는 커널은 쓰레드의 존재를 알지 못했습니다.
초기에는 커널은 쓰레드의 존재를 알지 못했습니다. 아마 그 당시에 쓰여진 표현 같네요.
초기 user level에서의 쓰레드 구현은 c library의 해킹으로 이루어졌습니다.
직접 c library를 수정하거나, 바이너리 상태에서 system call function pointer를 hooking하는 방식으로 구현되었습니다.
gnu pth thread 소스 보시는 것을 추천합니다.
https://www.gnu.org/software/pth/pth-manual.html
---
http://coolengineer.com
관련 운영체제 서적들을 뒤져보니...
성능상 주된 장점은 아무래도 아래 2가지 인 것 같습니다.
1. 프로세스 간 교환보다 스레드간 교환이 빠르다.
단순 레지스터 교환을 넘어 스레드는 메모리 공간 자체를 공유하기 때문에
메모리 공간과 각종 리소스 정보까지 메모리 교체를 해야하는 프로세스 교환보다 빠르다라고 하네요.
실제로 스레드 교환에 비해 캐싱 문제도 있을 것 같네요.
2. 스레드는 공유된 메모리 영역을 사용하기 때문에 프로세스 간 IPC 통신보다 빠르다.
(프로세스의 경우 메모리 보호로 인해 커널을 통해(시스템 콜) 통신이 이루어져야 하므로)
댓글 달기