Terminal: 기본 WSL 터미널 내부에 입력하는 것이 놀랍습니다. 다른 모든 앱보다 나은 이유는 무엇입니까?

누군가가 와서 우리가 어떤 일을 잘하고 있다고 말할 때 정말 신경 쓰지 않습니다. 우리는 매일 많은 불만을 듣고 이와 같은 게시물은 신선한 공기의 호흡입니다. 감사합니다!

또한 당신이 그것을 읽는 것에 지칠 때까지 나는 당신과 이것을 토론하게되어 기쁩니다. 원하는 후속 조치를 요청하십시오. 나는 내 일에 대해 번성합니다. :피

텍스트를 화면에 표시 할 때 Windows의 다른 응용 프로그램보다 우리를 더 빠르게 만드는 것이 무엇인지에 대해 교육적인 추측을해야한다면 말 그대로 우리의 유일한 작업이기 때문입니다! 또한 아마도 Windows가이 작업을 수행하는 데 필요한 가장 오래되고 가장 낮은 수준의 API를 사용하고 있기 때문일 것입니다.

나열한 거의 모든 것에는 일종의 레이어 또는 프레임 워크가 포함되어 있거나 Electron 및 Javascript에 대해 이야기하기 시작할 때 많은 레이어와 프레임 워크가 있습니다. 우리는 그렇지 않습니다.

추가 컨트롤이 첨부되지 않은 매우 특별하지 않은 창 하나가 있습니다. 우리는 우리보다 훨씬 복잡한 UI 프레임 워크 (WPF, WinForms, UWP, 전자). 그리고 주름없이 GDI의 PolyTextOut 을 사용하여 텍스트를 창 표면에 바로 덤프합니다.

notepad.exe 조차도 창에 여러 컨트롤이 있고 편집 컨트롤에서 일종의 라이브러리 프레임 워크를 사용하여 텍스트 레이아웃 (아마도 다른 라이브러리를 사용하고있을 것임)을 파악하고 있습니다. 국제화 지원을위한 프레임 워크 ...)

물론 이것은 우리에게 트레이드 오프가 있음을 의미하기도합니다. 우리는 다른 모든 응용 프로그램처럼 완전히 국제적인 텍스트를 지원하지 않습니다. RTL? 지금은 이동 영역이 없습니다. 서로 게이트 쌍과 그림 이모티콘? 우리는 거기에 도착했지만 아직 거기에 있지 않습니다. 인도어 스크립트? 아니.

우리는 왜 이런가요? 하나의 경우, conhost.exe 는 먼지처럼 오래되었습니다. 대부분의 다른 프레임 워크가 생성되기 전에 생성 되었기 때문에 모든 것의 베어 메탈 하단 레이어를 사용해야합니다. 또한 프레임 워크 나 프레임 워크에 필요한 모든 기능을 갖추기 전에 새 운영 체제 버전 또는 장치를 가져올 때 가장 먼저 가져와야하는 것이기 때문에 가능한 한 낮은 / 하위 수준을 유지합니다. 작동합니다. 또한 C / C ++로 작성되었는데, 이는 우리가 얻을 수있는만큼 낮고 베어 메탈입니다.

이 UI 향상이 Windows의 다른 앱에도 적용됩니까? 거의 확실하지 않습니다. 그들은 좋은 일과 나쁜 일을 너무 많이합니다. 수동으로 픽셀을 계산하거나 글꼴에 적용되는 스타일에 신경을 쓰지 않고 모든 언어에서 복잡한 방식으로 하나의 메서드와 레이아웃 텍스트를 호출 할 수있는 능력이 부럽습니다. 그러나 수동 픽셀 계산, 더티 영역 수학, 스크롤 영역 광기 등은 우리가 그들보다 더 빠르게 진행할 수 있도록합니다. 나는 또한 누군가가 "창 하단에 상태 표시 줄을 추가 할 수 있니?"라고 말하면 UI 프레임 워크를 사용하여 거의 클릭하여 제자리로 드래그 할 수 있으며 우리와 같은 곳에서 작동 할 것이라는 점이 부럽습니다. 영원히 백 로그 항목이었고 구현에 대해 생각할 때 가슴 앓이를 제공합니다.

퇴보하지 않도록 노력할까요? 예! 지금은 일종의 수동 프로세스입니다. 무언가가 느려지고 있음을 확인한 다음 WPR을 꺼내 추적을 시작합니다. 우리는 뜨거운 길을 쳐다보고 무슨 일이 일어나고 있는지 추론하고 개선하려고 노력합니다. 예를 들어, 마지막 한두주기에서 우리는 엔드-투-엔드 성능을 향상시킬 수있는 주요 영역으로 힙 할당에 초점을 맞추고 기본 요청에 대해 스택으로 구성된 반복기와 같은 파사드를 사용하도록 코드의 톤을 변경했습니다. 각 처리 수준에 대해 새 힙 공간으로 변환 및 할당하는 대신 버퍼를 사용합니다.

제쳐두고 @bitcrazed 는 특정 방식으로 성능 테스트를 자동화하기를 원하지만 아직이를 수행 할 제어 된 환경을 아직 파악하지 못했습니다. Windows Engineering System은 매일 밤 성능 테스트를 실행하여 전체 운영 체제에서 무언가를 엉망으로 만들 었는지 알 수있는 대략적인 방법을 제공하며 기술적으로는 자체 성능 테스트를 삽입 할 수있는 세밀한 방법을 제공합니다. 아직 그것에 대해 이해하지 못했습니다. 자동화 된 방식으로이 작업을 수행 할 수있는 방법에 대한 아이디어가 있다면 모두 귀를 기울입니다.

더 알고 싶은 것이 있으면 알려주세요. 하루 종일 갈 수 있습니다. 나는 그것을 게시하기 전에이 답장에서 15 개의 탄젠트처럼 삭제했습니다 ....

저수준 Windows API에 대해 말하면 콘솔 (conhost.exe, cmd.exe ...) 및 WSL (wsl.exe, LxssManager.dll ...)의 모든 _user mode_ 구성 요소가 C ++ _STL_을 엄청나게 사용한다는 것을 발견했습니다. 예를 들어 문자열 조작, 메모리 할당, 가상 테이블 등에서 C 만 사용하면 성능이 향상됩니까?

C ++ STL을 "엉뚱하게"사용하는 것으로 간주하지 않습니다. 그들은 확실히 컬렉션의 일부와 아마도 약간의 문자열 조작과 알고리즘을 여기저기서 사용합니다. 나는 STL에 그 몇 비트보다 더 많은 것이 있다고 느낍니다.

하지만 어쨌든 ... 당신이 설명하는 대부분의 것은 C로 똑바로 쓰여졌습니다. 우리는 의식적인 절충안으로 C ++와 STL을 점점 더 많이 사용하고 있습니다. 템플릿이 내부에서 수행하는 작업을 잘 알고 올바른 템플릿을 신중하게 사용하는 한 일반적으로 보안 및 프로그래밍 편의성을 크게 확보하면서 매우 적은 양의 성능 만 거래합니다.

보안은 실제로 가능할 때마다 자체 구조를 만드는 것보다 STL 템플릿을 사용하는 가장 큰 이유입니다. 컬렉션과 문자열에 STL 템플릿을 사용하면 일반적으로 오류가 발생하기 쉬운 방식으로 수동으로 수행해야하는 경계 검사를 수행 할 수 있습니다 (또는 전혀 수행하지 않음).

또한 콘솔 코드 내부에 17 개의 다른 큐잉 및 연결 목록 구현이있는 경우 C가 오늘 std :: queue 및 std :: list를 사용하는 것보다 성능면에서 전반적으로 더 나은지 확신 할 수 없습니다. 다른 유형의 성능 문제 (스토리지 및 페이지로드 I / O) 인 각 개별 구현에 대해 더 많은 디스크 공간을 소비했을 것입니다.

시간을내어 답장을 써 주셔서 감사합니다. 칭찬에는 문제 없습니다.

지난 몇 달 동안 저는 좋은 터미널 설정을 찾고 있었는데, tmux를 사용하는 ubuntu.exe 은 오늘날 우리가 가지고있는 도구로 얻을 수있는 것만 큼 완벽에 가깝다고 생각합니다. ubuntu.exe 터미널 자체는 엄청나게 빠르며 tmux는 인생의 모든 혜택 (탭, 분할 창, 버퍼 검색 등)을 제공합니다.

색상 테마의 호환성을 높이는 향후 릴리스와 글꼴 크기 +/- 확대를위한 단축키와 같은 속성 관련 개선 사항을 정말 기대하고 있습니다.

@miniksa : 매우 흥미로운 게시물에 감사드립니다!

우리는 Windows가이 작업을 수행하는 데 필요한 가장 오래되고 가장 낮은 수준의 API 근처에서 darn을 사용하고 있습니다.

나는 이것에 대해 한동안 궁금했습니다. 다양한 Win32 API (USER32 / GDI32)를 참조하는 것으로 보입니다. 최근에 Windows의 최신 버전 (8.0 이상)에서 얻을 수있는 것처럼 여전히 낮은 수준인지 또는 이러한 API가 다른 항목 (예 : Direct2D, DirectWrite 등). 이전 API는 최신 API와 어떤 관련이 있습니까? 당신이 그 부분을 명확히 할 수 있다면 나는 그것을 좋아할 것입니다!

@stakx , USER32 및 GDI32를 참조하고 있습니다.

세부 사항을 확인하는 데 몇 시간을 소비하지 않고 내가 알고있는 내용에 대한 간단한 개요를 제공하겠습니다. 따라서이 중 일부는 손으로 흔드는 경우가 있으며 약간 부정확 할 수 있지만 올바른 방향 일 수 있습니다. 모든 진술을 세상이 어떻게 돌아가는지에 대한 나의 개인적인 지식으로 간주하고 의견이나 오류의 영향을받습니다.

파이프 라인의 그래픽 부분 (GDI32)의 경우 GDI의 사용자 모드 부분은 상당히 아래에 있습니다. 앱은 GDI32를 호출하고 일부 작업은 사용자 모드 측에서 해당 DLL에서 수행 된 다음 커널 호출이 커널로 이동하여 그리기가 발생합니다.

"다른 항목 위에 앉기 위해 자동으로 변환"에 대해 생각하는 부분은 아마도 커널 호출을 받으면 커널 GDI 항목이 다음과 같은 항목 위에 다시 플랫폼되는 경향이 있다는 것입니다. DirectX가 실제로 NVIDIA / AMD / Intel 등에서 처리되는 경우. 그래픽 드라이버와 GPU는 스택 맨 아래에 있습니다. Windows Vista 용 WDDM의 일부로 제공되는 그래픽 드라이버 재 아키텍처에서 이런 일이 발생했다고 생각합니다. 어딘가에 GDI에서 호출이 여전히 정말 빠르고 플랫폼을 재 구축 한 결과 더 느린 것에 대한 문서가 있습니다. 지난번에 그 문서를 찾아서 확인했을 때 빠른 문서를 사용하고있었습니다.

GDI 외에도 더 좋은 선언적 프레임 워크를 갖기 전에 UI를 만들기 위해 재사용 가능한 단추 및 요소 집합을 제공하는 Common Controls 또는 comctl32.dll과 같은 것이 있다고 생각합니다. 콘솔에서는 실제로 사용하지 않습니다 (오른쪽 클릭 메뉴의 속성 시트 제외).

DirectWrite와 D2D, D3D 및 DXGI 자체는 사용자 모드와 커널 모드 모두에서 GDI에서 완전히 벗어난 별도의 명령 및 경로 집합입니다. 둘 사이에 상호 운용성 조항이 있다는 것 외에는 실제로 관련이 없습니다. 하지만 대부분의 다른 UI 프레임 워크는 DirectX 스택 위에 구축되는 경향이 있습니다. XAML은 확실합니다. WPF가 있다고 생각합니다. WinForms에 대해 잘 모르겠습니다. 그리고 컴포지션 스택과 창 관리자도 DirectX를 사용하고 있다고 생각합니다.

파이프 라인의 입력 / 상호 작용 부분 (USER32)에 관해서는 대부분의 다른 새로운 것 (적어도 데스크톱 PC의 경우)이 이미 존재하는 것 위에 구축되는 경향이 있습니다. USER32의 주요 개념은 창과 창 핸들이며 모든 것이 창 핸들로 전송됩니다. 데스크톱 컴퓨터 (또는 랩톱 또는 기타 ... 고전적인 스타일의 Windows 기반 컴퓨터)를 사용하는 한 관련 창 핸들과 메시지가 떠다니며 이는 우리가 USER32에 대해 이야기하고 있음을 의미합니다.

창 메시지 대기열은 전경에있는 동안 해당 창과 관련하여 발생한 모든 입력 + 시스템의 다른 구성 요소에 의해 창으로 전송 된 모든 항목의 단순한 FIFO (대부분 또는 적음)입니다.

새로운 기술과 XAML, WPF 및 WinForms와 같은 프레임 워크는 창 메시지 대기열에서 메시지를 어떤 방식 으로든 받아 처리하고이를 세계 내에서 프로비저닝 한 다양한 개체에 대한 이벤트 콜백으로 변환하는 경향이 있습니다.

그러나 XAML과 같은 다른 비 데스크톱 플랫폼에서도 작동하는 최신 기술은 완전히 다른 비 USER32 스택에서도 처리 할 수있는 능력이 있습니다. USER32에 대한 별도의 병렬 스택이 있으며, 기존 메시징 대기열과 창 처리를 정확히 동일한 방식으로 처리하지 않는 입력 및 상호 작용이 발생하는 방식에 대한 모든 새로운 혁신 및 실현이 있습니다. 이것은 CoreWindow 및 CoreMessaging과 같은 전체 Core * 제품군입니다. 그들은 또한 책상 위에 키보드와 마우스가있는 화면 앞의 구르는 의자에서 엉덩이를 중심으로하지 않는 "사용자는 무엇인가"라는 다른 개념을 가지고 있습니다.

이제 XAML 또는 다른 프레임 워크 중 하나를 사용하는 경우이 모든 복잡성이 처리됩니다. XAML은 DirectX에서 그리는 방법을 파악하고 사용자를 대신하여 멋진 효과를 얻기 위해 컴포 지터 및 창 관리자와 협상합니다. USER32 또는 Core *에서 입력 이벤트를 가져올 지 또는 플랫폼 및 입력 스택에 따라 투명하게 가져올 지 여부를 파악하여 펜, 터치, 키보드, 마우스 등을 통합 된 방식으로 처리 할 수 ​​있습니다. 그것은 당신의 삶을 쉽게 만드는 모든 종류의 세계화, 접근성, 입력 상호 작용 등을 수행하기 위해 내부에 포함 된 조항을 가지고 있습니다. 그러나 저수준으로 직접 이동하여 직접 처리하거나 신경 쓰지 않는 것은 건너 뛰도록 선택할 수 있습니다.

트릭은 GDI32 및 USER32가 제한된 명령 집합으로 제한된 세계를 위해 설계되었다는 것입니다. 데스크톱 PC는 키보드와 마우스의 단일 사용자, VGA 모니터에 대한 간단한 그래픽 출력이었던 유일한 존재였습니다. 따라서 conhost처럼 "낮은 수준"에서 직접 사용하는 것은 매우 쉽습니다. 새로운 플랫폼은 "낮은 수준"에서 사용될 수 있지만 20 년 이상 동안 다양한 폼 팩터, 여러 활성 사용자, 여러 그래픽 어댑터와 같이 개인용 컴퓨팅에서 발생한 모든 일을 설명하기 때문에 훨씬 더 복잡합니다. 그리고 계속해서 계속해서. 따라서 새로운 것을 사용할 때 프레임 워크를 사용하여 머리가 터지지 않도록하는 경향이 있습니다. 그들은 당신을 위해 그것을 처리하지만 이전보다 더 많이 처리하므로 어느 정도 느립니다.

그렇다면 GDI32와 USER32는 새로운 것보다 "낮은"것입니까? 일종의.
최신 제품으로 그 정도를 낮출 수 있습니까? 대부분 그렇습니다.하지만 당신은 아마 그렇게해서는 안되며 원하지도 않을 것입니다.
새로운 것이 오래된 것 위에 살거나 오래된 것이 새 것 위에 다시 플랫폼됩니까? 때때로 그리고 / 또는 부분적으로.
기본적으로 ... 모든 소프트웨어에 대한 대답과 같습니다. "완전한 재난이며 우리 모두가 잠시 뒤로 물러 나면 전혀 작동하지 않는다는 사실에 놀랄 것입니다." :피

어쨌든, 어느 날 아침이면 충분합니다. 그것이 당신의 질문에 다소 대답하고 조금 더 많은 통찰력을 줬기를 바랍니다.

그것이 당신의 질문에 다소 대답하고 조금 더 많은 통찰력을 줬기를 바랍니다.

@miniksa , 실제로 그랬습니다! 또한 완벽합니다. 시간을내어 모든 것을 작성해 주셔서 대단히 감사합니다! : +1 :

지금은이 문제를 종료하겠습니다. 문의 해 주셔서 감사 드리며 정보가 즐거워서 기쁩니다.