Windows에서 새로운 프로세스를 작성하는 것이 Linux보다 비싼 이유는 무엇입니까?

Windows에서 새로운 프로세스를 작성하는 것이 Linux보다 비싼 이유는 무엇입니까?

윈도우 박스에서 새로운 프로세스를 만드는 것이 Linux보다 더 비싸다고 들었어요.정말이에요?왜 가격이 비싼지에 대한 기술적 이유를 설명하고 이러한 이유의 배경에 있는 설계 결정의 역사적 이유를 설명할 수 있는 사람이 있습니까?

mweerden: NT는 첫날부터 멀티 유저용으로 설계되어 있기 때문에, 이것은 실제로 이유가 되지 않습니다.단, 프로세스 작성은 Unix와 대조적으로 Unix에서 멀티스레딩을 선호하기 때문에 NT에서 Unix에서보다 덜 중요한 역할을 합니다.

롭, COW를 사용할 때 포크가 상대적으로 저렴한 것은 사실이지만, 사실 포크는 대부분 경영진이 뒤따릅니다.또한 모든 이미지를 로드해야 합니다.그러므로 포크의 성능을 논하는 것은 진실의 일부일 뿐이다.

프로세스 작성 속도를 설명할 때는 NT와 Windows/Win32를 구별하는 것이 좋습니다.NT(커널 자체)에 관한 한 프로세스 작성(NtCreateProcess)과 스레드 작성(NtCreateThread)은 평균적인 Unix보다 현저하게 느리다고 생각하지 않습니다.조금 더 많은 문제가 있을 수 있지만 성능 차이가 나는 주된 이유는 알 수 없습니다.

그러나 Win32를 보면 프로세스 작성에 상당한 오버헤드가 발생한다는 것을 알 수 있습니다.우선 프로세스 작성에 대해 CSRSS에 통지해야 합니다.이 경우 LPC가 포함됩니다.적어도 커널32를 추가로 로드해야 하며 프로세스가 완전한 Win32 프로세스로 간주되기 전에 수행해야 할 몇 가지 추가 부기 작업 항목을 수행해야 합니다.매니페스트 해석, 이미지에 호환성 심이 필요한지 여부, 소프트웨어 제한 정책 적용 여부 확인에 따른 추가 오버헤드도 잊지 마십시오.

즉, 프로세스, VA 공간 및 초기 스레드의 원시 생성과 더불어 수행해야 하는 모든 사소한 작업의 합계가 전반적으로 느려지는 것을 알 수 있습니다.그러나 처음에 말했듯이 멀티태스킹보다 멀티스레딩을 선호하기 때문에 이 추가 비용의 영향을 크게 받는 유일한 소프트웨어는 Unix 소프트웨어입니다.Chrome 및 IE8과 같은 소프트웨어가 갑자기 멀티 프로세싱의 이점을 재발견하고 프로세스를 자주 시작 및 해체하기 시작하면 상황이 바뀌지만...

JP가 말한 것에 덧붙여, 프로세스의 오버헤드의 대부분은 Win32의 스타트업에 속합니다.

Windows NT 커널은 실제로 COW 포크를 지원합니다.SFU(Microsoft의 Windows용 UNIX 환경)가 이를 사용합니다.그러나 Win32는 포크를 지원하지 않습니다.SFU 프로세스는 Win32 프로세스가 아닙니다.SFU는 Win32와 직교합니다.둘 다 같은 커널 상에 구축되어 있는 환경 서브시스템입니다.

LPC 에의 해, LPC 에의 콜도 .CSRSSXP 이후에는 응용 프로그램 호환성 데이터베이스에서 프로그램을 찾기 위해 응용 프로그램 호환성 엔진에 대한 프로세스 외 호출이 발생합니다.이 절차로 인해 Microsoft는 퍼포먼스상의 이유로 WS2003의 호환성 엔진을 무효로 하는 그룹 정책 옵션을 제공하고 있기 때문에 충분한 오버헤드가 발생합니다.

또한 Win32 런타임 라이브러리(커널32.dll 등)는 UNIX, SFU 또는 네이티브 프로세스에 적용되지 않는 많은 레지스트리 읽기 및 초기화를 실행합니다.

네이티브 프로세스(환경 서브시스템 없음)는 매우 빠르게 작성할 수 있습니다.SFU는 프로세스 작성에 Win32보다 훨씬 적은 작업을 수행하므로 프로세스 작성도 신속합니다.

2019년 업데이트: LXSS: Linux용 Windows 서브시스템 추가

Windows 10 의 SFU 를 대체하는 것은, LXSS 환경 서브 시스템입니다.100% 커널 모드이며 Win32가 계속 사용하는 IPC는 필요 없습니다.이러한 프로세스의 Syscall은 lxss.sys/lxcore.sys로 직접 전송되므로 fork() 또는 콜을 작성하는 다른 프로세스에는 총 1개의 시스템콜만 비용이 듭니다[인스턴스라고 불리는 데이터 영역]는 모든 LX 프로세스, 스레드 및 런타임 상태를 추적합니다.

LXSS 프로세스는 Win32 프로세스가 아닌 네이티브 프로세스를 기반으로 합니다.호환성 엔진 등 Win32 고유의 모든 것은 전혀 관여하고 있지 않습니다.

Unix에는 현재 프로세스를 2개로 분할하는 '포크' 시스템 호출이 있으며 첫 번째 프로세스와 동일한 두 번째 프로세스(포크 호출로부터의 반환 모듈화)를 제공합니다.새로운 프로세스의 주소 공간이 이미 가동되고 있기 때문에 Windows에서 'Create Process'를 호출하여 exe 이미지, 관련 dll 등을 로드하는 것보다 비용이 저렴합니다.

포크의 경우 OS는 양쪽 새로운 프로세스와 관련된 메모리 페이지에 대해 "copy-on-write" 시멘틱스를 사용하여 각각의 프로세스가 나중에 수정되는 페이지의 복사본을 얻을 수 있습니다.

Rob Walker의 답변 외에 최근에는 Native POSIX 스레드 라이브러리 같은 것이 준비되어 있습니다.그러나 오랜 기간 동안 UNIX 환경에서 작업을 "위임"하는 유일한 방법은 fork()를 사용하는 것이었습니다(그리고 여전히 많은 상황에서 선호되고 있습니다).(소켓 서버 등)

socket_accept()포크()if (자녀)handleRequest()또 다른goOn Being Parent()

Therefore the implementation of fork had to be fast and lots optimizations have been implemented over time. Microsoft endorsed CreateThread or even fibers instead of creating new processes and usage of interprocess communication. I think it's not "fair" to compare CreateProcess to fork since they are not interchangeable. It's probably more appropriate to compare fork/exec to CreateProcess.

이 문제의 핵심은 두 시스템의 역사적 사용이라고 생각합니다.Windows(및 그 이전의 DOS)는 원래 개인용 컴퓨터를 위한 단일 사용자 시스템이었습니다.따라서 이러한 시스템은 일반적으로 항상 많은 프로세스를 생성할 필요가 없습니다.간단히 말하면, 이 외로운 유저가 프로세스를 요구할 때만 프로세스가 생성됩니다(그리고 우리 인간은 비교적 빠르게 동작하지 않습니다).

Unix 기반 시스템은 원래 다중 사용자 시스템 및 서버였습니다.특히 후자의 경우 특정 작업을 처리하기 위해 프로세스를 분리하는 프로세스(예: 메일 또는 http 데몬)가 있는 경우가 드물지 않습니다(예: 들어오는 연결 하나를 처리하는 경우).이다.fork(Rob Walker(47865)에서 언급한 바와 같이 처음에 새로 생성된 프로세스에 동일한 메모리를 사용함) 방법을 사용하면 새로운 프로세스에 필요한 모든 정보가 즉시 제공되므로 매우 유용합니다.

적어도 역사적으로 Unix 기반 시스템이 Windows 시스템보다 훨씬 더 빠른 프로세스 생성을 필요로 한다는 것은 분명합니다.유닉스 베이스의 시스템은 아직 프로세스 지향적인 반면, Windows는 그 역사 때문에 스레드 지향적인 경향이 강하기 때문에(스레드는 응답성이 뛰어난 애플리케이션을 만드는 데 도움이 됩니다).

면책사항:저는 이 문제에 대해서는 전문가가 아니기 때문에 틀렸더라도 용서해 주십시오.

간단히 말하면 "소프트웨어 계층 및 컴포넌트"입니다.

Windows SW 아키텍처에는 Unix에는 존재하지 않는 추가 레이어 및 컴포넌트가 몇 개 있습니다.또한 Unix의 커널 내에서 심플화되어 처리됩니다.

UNIX 에서는, fork 와 exec 는 커널에의 다이렉트콜입니다.

Windows 에서는 커널 API는 직접 사용되지 않으며, 그 위에 win32 및 기타 특정 컴포넌트가 있기 때문에 프로세스 작성은 추가 레이어를 거쳐 새로운 프로세스가 시작되거나 이들 레이어 및 컴포넌트에 접속되어야 합니다.

오랜 시간 동안 연구자들과 기업들은 보통 마하 커널을 기반으로 하는 막연한 방식으로 Unix를 분리하려고 시도했습니다. 잘 알려진 예는 OS X입니다.그러나 매번 너무 느려지기 때문에 적어도 부분적으로는 커널에 영구적 또는 실제 출하용으로 머지하게 됩니다.

어, "이것이 더 낫다"는 식의 정당화가 진행되고 있는 것 같습니다.

나는 사람들이 윈도우 NT의 개발에 관한 책인 "쇼스토퍼"를 읽는 것이 도움이 될 것이라고 생각한다.

Windows NT의 한 프로세스에서 DLL로 서비스가 실행되는 이유는 다른 프로세스로 인해 너무 느리기 때문입니다.

만약 당신이 주저앉아 더러워진다면, 당신은 라이브러리 로딩 전략이 문제라는 것을 알게 될 것이다.

Unices(일반)에서는 공유 라이브러리(DLL) 코드 세그먼트가 실제로 공유됩니다.

Windows NT는 로드 후 라이브러리 코드 세그먼트(및 실행 가능한 코드 세그먼트)를 조작하기 때문에 프로세스별로 DLL 복사본을 로드합니다.(데이터는 어디에 있습니까?)

이로 인해 라이브러리의 코드 세그먼트는 재사용할 수 없게 됩니다.

NT 프로세스 작성은 실제로 비용이 많이 듭니다.또한 DLL을 메모리 내에서 크게 절약할 수는 없지만 애플리케이션 간 종속성 문제가 발생할 수 있습니다.

때때로 엔지니어링 부문에서는 한 발짝 물러서서 이렇게 말할 수 있습니다. "만약 우리가 이걸 정말 형편없게 설계한다면, 어떻게 보일까?"

옛날에는 꽤 변덕스러운 임베디드 시스템을 사용했는데어느 날 그것을 보고 전자레인지 캐비티 마그네트론이라는 것을 깨달았습니다그 후, 전자레인지보다 훨씬 안정적이게 되었습니다.

MS-Windows에 대한 일부 답변이 타당하다고 생각되기 때문입니다.

• "NT 커널과 Win32는 같은 것이 아닙니다.NT 커널에 프로그래밍하면 그렇게 나쁘지 않습니다."-맞습니다만, Posix 서브시스템을 쓰고 있지 않는 한, 어느 쪽이라도 상관없습니다.win32에 기입합니다.
• 「프로세스 작성과 Windows 에는 포크가 없기 때문에, 포크를 비교하는 것은 공평하지 않습니다.」-그렇습니다.따라서 이와 같이 비교하겠습니다.그러나 포크는 프로세스 분리(예: 웹 브라우저의 각 탭은 서로 다른 프로세스로 실행됨)와 같은 많은 사용 사례가 있기 때문에 비교도 해 보겠습니다.

이제 사실을 살펴보겠습니다. 성능의 차이는 무엇입니까?

데이터는 http://www.bitsnbites.eu/benchmarking-os-primitives/에서 여름화.
할 때는 합니다.
2개의 코어 i7 8 코어 3.2 Gnu/ GHz를 (Gnu/Linux)

Linux의 "Linux"fork하는 메서드 MS-Window보다 .CreateThread.

프로세스 생성 유형 작업에 대한 숫자입니다(차트에서 리눅스 값을 보기 어렵기 때문입니다).

속도 순으로 빠른 것부터 느린 것까지(숫자는 시간, 작은 것이 좋다).

• Linux Create Thread 12
• Mac Create Thread 15
• Linux 포크 19
• Windows Create Thread 25
• Linux Create Process (fork + exec) 45
• 맥 포크 105
• Mac Create Process (fork + exec) 453
• Rasberry-Pi Create Process (fork+exec) 501
• Windows Create Process 787
• Windows Create Process With 바이러스 스캐너 2850
• Windows Fork (Create Process + fixup으로 시뮬레이트)2850 이상

기타 측정에 대한 숫자

• 일을만만 만만만다다
  • Linux 13
  • Mac 113
  • Windows 225
  • Lasberry-Pi(저속 SD카드 탑재) 241
  • Windows Defender 및 바이러스 스캐너 등12950
• 메모리 할당
  • Linux 79
  • 윈도 93
  • 맥 152

게다가 Win 머신에서는, 대부분의 경우 Create Process중에 안티바이러스 소프트웨어가 기동합니다.보통 가장 큰 속도 저하입니다.

또, Windows 의 시큐러티 모델은, Unix 베이스의 OS 에 비해 매우 복잡하기 때문에, 프로세스 작성시의 오버헤드가 커집니다.또한 Windows에서 멀티 프로세싱보다 멀티스레딩을 선호하는 또 다른 이유도 있습니다.

언급URL : https://stackoverflow.com/questions/47845/why-is-creating-a-new-process-more-expensive-on-windows-than-linux