라이브러리를 사용하는 동안 효율성을 부여하기 어려운 이유는 무엇입니까?

작은 데이터베이스 처리는 언어 자체의 라이브러리 및 / 또는 유틸리티를 사용하는 Python / Perl / ... 스크립트로 쉽게 처리 할 수 ​​있습니다. 그러나 성능과 관련하여 사람들은 C / C ++ / 저수준 언어를 찾는 경향이 있습니다. 코드를 필요에 맞게 조정할 수있는 가능성은 메모리 관리, 병렬 처리, 디스크 액세스 또는 심지어 낮은 수준의 최적화 (C / C ++ 수준의 어셈블리 구성을 통한)와 같은 빅 데이터에 이러한 언어를 매력적으로 만드는 것으로 보입니다.

물론 이러한 이점은 비용이 들지 않을 것입니다. 코드를 작성하고 때로는 바퀴를 재창조하는 것은 비용이 많이 들고 힘들 수 있습니다. 사용 가능한 라이브러리가 많이 있지만 사람들은 성능 을 부여 해야 할 때마다 스스로 코드를 작성하는 경향이 있습니다. 큰 데이터베이스를 처리하는 동안 성능 어설 션이 라이브러리를 사용 하지 못하게하는 것은 무엇입니까 ?

예를 들어, 웹 페이지를 지속적으로 크롤링하고 수집 된 데이터를 구문 분석하는 기업가를 생각해보십시오. 각 슬라이딩 창에 대해 추출 된 데이터에 대해 서로 다른 데이터 마이닝 알고리즘이 실행됩니다. 개발자가 사용 가능한 라이브러리 / 프레임 워크 (크롤링, 텍스트 처리 및 데이터 마이닝)를 사용하는 이유는 무엇입니까? 이미 구현 된 것을 사용하면 전체 프로세스를 코딩하는 부담을 덜어 줄뿐만 아니라 많은 시간을 절약 할 수 있습니다.

한 번에 :

• 스스로 코드를 작성하여 성능을 보장 하는 것은 무엇입니까?
• 고성능을 보장 해야 할 때 프레임 워크 / 라이브러리에 의존하는 것이 왜 위험 합니까?

재 작성 게임을 반복해서 해왔고 (그리고 여전히 그렇게하고 있음), 나의 즉각적인 반응은 적응력 이었습니다 .

프레임 워크와 라이브러리에는 표준 작업에 대한 (아마도 서로 얽힐 수있는) 루틴이 많이 있지만 프레임 워크 속성은 종종 (항상?) 단축키를 허용하지 않습니다. 실제로 대부분의 프레임 워크에는 기본 기능의 핵심 계층이 구현되는 일종의 핵심 인프라가 있습니다. 보다 구체적인 기능은 기본 계층을 사용하며 코어 주위의 두 번째 계층에 배치됩니다.

이제 바로 가기라는 것은 코어를 사용하지 않고 두 번째 계층 루틴에서 다른 두 번째 계층 루틴으로 곧장가는 것을 의미합니다. 내 도메인의 일반적인 예는 타임 스탬프입니다. 타임 스탬프가 지정된 데이터 소스가 있습니다. 지금까지의 작업은 단순히 와이어에서 데이터를 읽고 코어로 전달하여 다른 코드가이를 처리하는 것입니다.

이제 귀하의 산업은 매우 좋은 이유로 기본 타임 스탬프 형식을 변경합니다 (제 경우에는 유닉스 시간에서 GPS 시간으로 변경). 프레임 워크가 산업별로 다르지 않으면 시간의 핵심 표현을 기꺼이 바꾸지 않을 가능성이 높기 때문에 원하는 것을 거의 수행 하는 프레임 워크를 사용하게 됩니다. 데이터에 액세스 할 때마다 먼저 업계 시간 형식으로 변환해야하며 데이터를 수정하고자 할 때마다 코어가 적절하다고 생각하는 것으로 다시 변환해야합니다. 이중 변환없이 소스에서 싱크로 데이터를 바로 넘길 수있는 방법은 없습니다.

이곳은 수작업으로 제작 된 프레임 워크가 빛을 발하는 곳이며, 사소한 변경 일 뿐이며 실제 환경을 다시 모델링하는 반면, 다른 모든 (업종별이 아닌) 프레임 워크에는 성능상의 단점이 있습니다.

시간이 지남에 따라 실제 세계와 모델 간의 불일치가 더해집니다. 기성 프레임 워크를 사용하면 곧 같은 질문에 직면 할 것 : 나는 나타낼 수있는 방법 this에 that또는 메이크업 루틴 어떻게 X/ 생산을 허용 Y.

지금까지 이것은 C / C ++에 관한 것이 아닙니다. 그러나 어떤 이유로 프레임 워크를 변경할 수없는 경우 즉, 데이터를 한 쪽 끝에서 다른 쪽 끝으로 이동하기 위해 데이터를 이중으로 변환해야하는 경우 일반적으로 추가 오버 헤드를 최소화하는 것을 사용합니다. 필자의 경우 TAI-> UTC 또는 UTC-> TAI 변환기가 원시 C (또는 FPGA)에 가장 적합합니다. 우아함, 문제를 사소한 심오한 스마트 데이터 구조는 없습니다. 지루한 스위치 문 일 뿐이며 컴파일러가 정확히 최적화하는 데 도움이되는 언어를 사용하지 않는 이유는 무엇입니까?

성능이 문제가 될 때 모든 사람이 C / C ++에 도달한다고 생각하지 않습니다.

저수준 코드 작성의 장점은 적은 CPU주기 또는 때로는 적은 메모리를 사용한다는 것입니다. 그러나 고급 언어는이 언어의 일부를 얻기 위해 하위 언어로 내려갈 수 있습니다. 파이썬과 JVM 언어가 이것을 할 수 있습니다.

예를 들어, 데스크톱에서 scikit-learn을 사용하는 데이터 과학자는 이미 숫자 크 런칭을 수행하기 위해 고도로 최적화 된 기본 루틴을 호출하고 있습니다. 속도를위한 새로운 코드를 작성할 필요는 없습니다.

분산 된 "빅 데이터"컨텍스트에서는 네트워크 전송 및 I / O와 같은 데이터 이동에 병목 현상이 발생합니다. 네이티브 코드는 도움이되지 않습니다. 더 빠른 실행을 위해 동일한 코드를 작성하는 것이 아니라 더 똑똑한 코드를 작성하는 것이 도움이됩니다.

고급 언어를 사용하면 C / C ++보다 주어진 개발자 시간에보다 정교한 분산 알고리즘을 구현할 수 있습니다. 규모가 커질수록 더 나은 데이터 이동을 가진 똑똑한 알고리즘은 멍청한 원시 코드를 능가합니다.

일반적으로 개발자 시간과 버그로 인해 새로운 하드웨어보다 많은 비용이 소요되는 것도 사실입니다. 1 년 간의 수석 개발자 시간은 완전히로드 된 $ 200K 일 수 있습니다. 1 년에 걸쳐 수백 대의 서버를 계산할 가치가 있습니다. 대부분의 경우 더 많은 하드웨어를 던지는 것에 대한 최적화를 방해하는 것이 합리적이지 않을 수 있습니다.

"grant"및 "disable"및 "assert"에 대한 후속 조치를 이해하지 못합니까?

아시다시피, 디지털 세계에는 동일한 작업을 수행하고 예상 결과를 얻는 여러 가지 방법이 있습니다.

코드에서 발생하는 책임 / 위험은 개발자의 어깨에 있습니다.

이것은 작지만 .NET 세계에서 매우 유용한 예를 생각합니다.

따라서 많은 .NET 개발자는 데이터 직렬화에 내장 BinaryReader-BinaryWriter를 사용하여 성능을 제어하고 프로세스를 제어합니다.

이것은 프레임 워크의 내장 BinaryWriter 클래스의 오버로드 된 Write 메소드 중 하나의 CSharp 소스 코드입니다.

// Writes a boolean to this stream. A single byte is written to the stream
// with the value 0 representing false or the value 1 representing true.
// 
public virtual void Write(bool value) 
{
     //_buffer is a byte array which declared in ctor / init codes of the class
    _buffer = ((byte) (value? 1:0));

    //OutStream is the stream instance which BinaryWriter Writes the value(s) into it.
    OutStream.WriteByte(_buffer[0]);
}

보다시피,이 메소드는 _buffer 변수에 추가로 할당하지 않고 작성할 수 있습니다 :

public virtual void Write(bool value) 
{
    OutStream.WriteByte((byte) (value ? 1 : 0));
}

할당하지 않으면 우리는 몇 밀리 초를 얻을 수있다.이 몇 밀리 초는 "거의 아무것도 없다"고 받아 들일 수 있지만 수천 개의 글이 있다면 (즉, 서버 프로세스에서)?

"몇"이 2 (밀리 초)이고 수천 인스턴스가 2.000에 불과하다고 가정합니다. 이는 프로세스 시간이 4 초 더 길다는 것을 의미합니다.

.NET을 계속 사용하고 MSDN에서 BCL-.NET 기본 클래스 라이브러리-의 소스 코드를 확인할 수 있으면 개발자가 결정한 많은 성능 손실을 확인할 수 있습니다.

BCL 소스의 요점 개발자가 코드에서 더 빠른 for () 루프를 구현할 수있는 while () 또는 foreach () 루프를 사용하기로 결정한 것이 일반적입니다.

이 작은 이익은 우리에게 총 성능을 제공합니다 ..

그리고 BinaryWriter.Write () 메소드로 돌아갑니다.

실제로 _buffer 구현에 추가로 할당하는 것은 개발자 결함이 아닙니다. 이것은 "안전한 상태"를 유지하기로 결정합니다!

_buffer를 사용하지 않고 두 번째 방법을 구현하기로 결정했다고 가정합니다. 두 번째 방법으로 와이어를 통해 수천 바이트를 보내려고하면 (즉, BLOB 또는 CLOB 데이터 업로드 / 다운로드) 두 번째 방법으로 실패 할 수 있습니다. 연결을 잃어 버렸습니다. 우리는 검사 및 제어 메커니즘없이 모든 데이터를 보내려고합니다.

개발자가 "안전한 체재"를 결정하면 일반적으로 성능 비용은 구현 된 "안전한 체재"메커니즘에 달려 있음을 의미합니다.

그러나 개발자가 "위험을 감수하고 성능을 향상 시키겠다"고 결정한 경우에도 이는 잘못된 일이 아닙니다.

그리고 작은 참고로 : 상용 라이브러리 개발자는 코드가 어디에 사용 될지 알 수 없기 때문에 항상 안전을 유지하려고 노력합니다.

프로그래머 관점에서 볼 때 프레임 워크는 성능을 최우선 순위로 삼는 경우가 거의 없습니다. 라이브러리를 널리 활용하려는 경우 사람들이 가장 중요하게 생각할 수있는 것은 사용 편의성, 유연성 및 안정성입니다.

성능은 일반적으로 2 차 경쟁 라이브러리에서 중요합니다. "X 라이브러리가 빠르기 때문에 더 좋습니다." 그럼에도 불구하고 그 라이브러리는 매우 자주 활용 될 수있는 가장 적합한 솔루션을 교환합니다.

프레임 워크를 사용하면 본질적으로 더 빠른 솔루션이 존재할 위험이 있습니다. 더 빠른 솔루션이 거의 항상 존재한다고 말할 수 있습니다.

직접 글을 쓰는 것은 성능을 보장하는 것은 아니지만, 수행중인 작업을 알고 있고 상당히 제한된 요구 사항이있는 경우 도움이 될 수 있습니다.

예를 들어 JSON 구문 분석이 있습니다. JSON을 참조 가능한 객체로 바꾸거나 그 반대로 할 다양한 언어를위한 백개의 라이브러리가 있습니다. CPU 레지스터에서 모두 수행하는 한 가지 구현을 알고 있습니다. 다른 모든 파서보다 훨씬 빠르지 만 매우 제한적이며 제한은 작업하는 CPU에 따라 다릅니다.

고성능 환경 특정 JSON 파서를 작성하는 작업이 좋은 생각입니까? 하나의 개별 인스턴스에서 몇 개의 추가 CPU 사이클에 백만 번의 반복을 곱하면 개발 시간이 가치가 있습니다.