정답
Q : 프로그래머가 항상 할로윈과 크리스마스를 혼동하는 이유는 무엇입니까?
A : 10 월 31 일 == 12 월 25 일이기 때문입니다!
2 바이트가 만났습니다. 첫 번째 바이트는 “아파요?”라고 묻습니다. 두 번째 바이트는 “아니요, 약간 기분이 좋지 않습니다.”라고 대답합니다.
Q : 전구를 바꾸려면 프로그래머가 몇 명이나 필요합니까?
A : 없음, 그게 하드웨어 문제
Q : 전구를 바꾸려면 몇 명의 Microsoft 프로그래머가 필요합니까?
A : 없음, 어둠을 표준으로 삼고 모든 사람에게 “이 동작은 의도적으로 설계된 것입니다. “
컴퓨터 과학 학생이 나무 아래에서 공부하고 다른 학생이 화려한 새 자전거를 타는 중입니다. 첫 번째 학생은”어디서 그거 샀어요? “라고 묻습니다. 자전거를 탄 학생이 대답합니다.” 제가 밖에서 공부하는 동안 한 아름다운 소녀가 자전거를 타서 옷을 모두 벗고 원하는 건 뭐든지 가질 수 있어요라고 말했습니다.” 첫 번째 학생은“좋은 선택입니다. 옷이 당신에게 맞지 않았을 것입니다.”라고 대답합니다.
물리학 자, 엔지니어, 프로그래머가 브레이크가 고장 났을 때 가파른 알파인 패스를 운전하는 차 안에있었습니다. 차는 점점 더 빨라지고 있었고, 그들은 모퉁이를 돌기 위해 고군분투하고 있었고, 미약 한 충돌 장벽이 한두 번만 산 옆으로 추락하는 것을 막았습니다. 그들은 갑자기 발견했을 때 모두 죽을 것이라고 확신했습니다. 그들은 탈출 차선으로 들어와 안전하게 정지했습니다. 물리학자는 “브레이크 패드의 마찰과 그에 따른 온도 상승을 모델링해야합니다. 고장 이유를 알아낼 수 있는지 확인해야합니다.”라고 말했습니다. 엔지니어는 “내가 뒤쪽에 스패너가 몇 개있는 것 같습니다. 내가”내가 무엇이 잘못되었는지 알아낼 수 있는지 살펴 보겠습니다 “라고 말했습니다. 프로그래머는 “다시 가서 재현 가능한지 확인하지 않는 이유는 무엇입니까?”라고 말했습니다.
Q : “부자가되는 객체 지향적 방법은 무엇입니까?”
A : 상속
프로그래머가 친구들에게 (또한 프로그래머) : “어제 밤에 섹시한 여자를 만났어요. 그녀를 집에 데려왔고 격렬하게 키스를 시작했습니다. 나는 그녀를 키보드에 앉히고 …”. 모든 친구들이 한마음으로 “집에 컴퓨터가 있어요?”라고 말했습니다. RAM은 무엇입니까? “
SQL 쿼리가 막대에 들어가 최대 두 개의 테이블로 이동하여”내가 함께 할 수 있습니까? “라고 묻습니다.
C ++, 모든 것이 엄지 손가락처럼 보이기 시작합니다.
Q : 전구를 바꾸려면 몇 명의 프롤로그 프로그래머가 필요합니까?
A : 예.
A 프로그래머는 잠자리에 들기 전에 침대 옆 탁자에 두 잔을 놓는다. 목이 마르면 가득 차고 목이 마르지 않을 때를 대비해 빈 것.
한 남자가 길가에 서서 담배를 하나씩 피우고 있습니다. “이봐,”그것들이 당신을 죽일 수 있다는 것을 모르십니까? 내 말은 “상자에 거대한 경고가 보이지 않았습니까?!” “괜찮습니다”라고 남자가 자연스럽게 “나”라고 말합니다. 엄마 컴퓨터 프로그래머 “.”그래서? 그게 무슨 상관이야? ” 부인이 물었다. 그는 “우리는 경고에 대해 신경 쓰지 않는다”고 대답했습니다. 우리는 오류에만 신경을 씁니다. “
세계에는 10 가지 유형의 사람들이 있습니다. 이진법을 이해하는 사람과 정기적 인 섹스를하는 사람.
그래서이 프로그래머는 데이트에 나갑니다. 뜨거운 병아리와 함께
답변
매우 나쁩니다.
그들은 “명백한”수정으로 미세 조정 된 시스템을 수정하고 절대적으로 최선의 의도로 모든 것을 끔찍하게 망칠 수있는 사람들입니다.
몇 가지 아이디어를 제공하기 위해 제가 아는 또 다른 훌륭한 엔지니어입니다. , Jeffrey Hsu는 ClickArray (현재는 Array Networks로 알려짐)에서 일하고 있었으며 실제로 성능에 중요한 작업을 수행하기 위해 또 다른 “큰 총”유형이 필요했기 때문에 저를 고용했습니다.
그리고 우리는 완료되었습니다.
1.3GHz Pentium 4 시스템 (2001 년)
우리는 1 초에 38,700 개 이상의 TCP 연결에 대한 역방향 프록시 캐시를 얻었습니다. 이는 인상적이지 않습니다. , INADDR\_ANY에 사용할 수있는 포트가 16,384 개뿐이라는 것을 알 때까지 BSD 또는 Linux 기반 시스템 인 경우 TCP / IP 스택을 확인합니다.
스택을 수정하지 않았습니다. BSD 스택 이었기 때문에 초기 페이지로드 요청에도 응답하고있었습니다. 같은 시간 프레임입니다.
그리고 우리는 다음 문제로 넘어갔습니다.
다음 문제가 나오기까지 약 반달이 걸립니다. 마침내 캐시의 나머지 코드에 대해 수행 한 변경 사항에 대해 성능 테스트를 수행 할 시간이 얼마 남지 않았습니다.
며칠 동안 문제가 무엇인지 여러 번 물었고, 문제에 대해 걱정하지 말라는 말을 듣고 계속 작업 중이었습니다.
우리는 유한 상태 머신을 수정하고 있었기 때문에 그렇게했습니다. 실제 유한 상태 머신이되고 당시 캐시 코드를 재구성합니다. 실제로 회사가 다음 자금을 지원하게 된 이유 중 하나입니다.
마지막으로 그들의 핫샷이 우리가 문제를 해결할 수 있는지 확인하기 위해 전화했습니다.
초당 약 6,300 개의 연결을 사용하고있었습니다.
성능면에서 약 6 배의 손실이 발생했으며 위치를 파악할 수 없었습니다.
몇 시간이 걸렸고 마침내 “다중 CPU 시스템을위한 최적화”커밋까지 추적했습니다.
우리는이를 해제하고 초당 약 35,000 개의 연결로 돌아가서 다시 조정했습니다. 몇 가지 핫 코드 경로를 확인하고 하루가 끝날 무렵 이전 수치로 백업했습니다.
최적화를 이해하려면 핫샷 프로그래머”는 그가 만들고 있다고 생각했습니다. 당시 스레딩은 그다지 중요하지 않았 음을 이해해야합니다.
그랬더라도 우리는 여전히 상태 머신을 통해 작업하고있었습니다. , 이는 전역 상태가 단일 “statite”객체로 이동되어 스레드별로 만들 수 있고 인스턴스가 서로 간섭하지 않도록하기 전에 수행되어야했습니다.
그래서 확장 모델은 다음과 같습니다. p로 여러 개의 “work to do”엔진이 있습니다. 프로세스, 그리고 요청이 들어 왔을 때 프로세스가 작업을 진행하도록하는 “게이트 키퍼”프로세스. 모든 요청을 확인한 다음 “프로세스를 중단”합니다. 더 많은 요청이있는 경우 게이트 키퍼의 kqueue는 “다른 프로세스를 중단”하는 등의 작업을 수행합니다.
우리의 “핫샷”은 한 프로세스가 거의 모든 요청 서비스를 수행하고 있음을 알았습니다. 다른 프로세스는 (대부분) 유휴 상태였습니다.
이것은 내가 “작업 할 작업”을 기다리는 프로세스에 FIFO 대신 LIFO를 의도적으로 사용했기 때문입니다.
그래서 그는 “수정했습니다. ”그것을 FIFO로 변경함으로써.
그리고 성능은 지옥으로 갔다.
내가 LIFO를 사용한 이유 첫 번째 장소는 코어간에 부하를 공유 할 필요가 없다는 것을 알았지 만 “핫샷”이 알지 못하는 몇 가지 사항을 알고 있었기 때문입니다.
나는 다음을 알고있었습니다.
- 네트워크 어플라이언스로서 우리는 광고 목적으로 공백 제거 또는 콘텐츠 재 작성과 같은 작업을 수행하기 위해 모듈에로드하지 않는 한 거의 항상 CPU가 아닌 I / O에 묶여있었습니다.
- 요점은 마지막으로 줄을서는 과정이 g는 모든 페이지를 코어에 두는 반면, 가장 오랫동안 유휴 상태였던 페이지는 아마도 모든 페이지를 코어에 두지 않았을 것입니다.
- 게다가 TLB 캐시 충돌이 발생했을 것입니다. 모든 사용자 공간 프로세스가 동일한 주소 범위에서 매핑되어 플러시가 발생했습니다.
- 즉, 최소한 L1 및 L2 캐시로 나가는 것을 의미하는 캐시 재로드가 필요함을 의미합니다.
- 결합하면 P4 아키텍처에 L3 캐시가 없기 때문에 추가 명령 파이프 라인 중단이 발생할 수 있습니다.
- 그래서 저는 의도적으로 추가로 유휴 CPU 사이클이 될 것이라고 알고있는 것을 교환했습니다. 내가 알고있는 코어는 최고의 I / O 바운드 성능을 가질 것입니다.
그래서 의도적으로 LIFO 주문을 선택하고 1994 년에 처음 사용했던 기술을 사용하여 성능 향상을 확인했습니다. 또는 소위 (내가이 기술을 발명했기 때문에) “핫 엔진 스케줄링”이라고 불렀습니다.
그래서이 “핫샷”은 pe 변경으로 인한 rformance.
그리고“최적화”라고 주장 된 후, 이것이 실제로 최적화인지 확인하기위한 성능 테스트를 실행하지 못했습니다.
그가 유일한 것은 d는로드 상태에서 프로세스가 시간이 지남에 따라 동일한 CPU 사용량에 대해 모두 표시되고 있다는 것을 확인했습니다. 이는 그가 더 나은 멀티 코어 사용률을 얻을 수 있다는 것을 의미했습니다.
절대적으로 최악의 소프트웨어 엔지니어는 위험 할만큼 훌륭하지만 잘못된 결정을 내릴 때 인식 할 수있을만큼 좋지 않은 엔지니어입니다.
공정한 통치자를 사용하여 변경 결과를 측정하여 결정이 실제로 나쁜 결정이라는 사실을 확인하지 않음으로써 더욱 악화됩니다.