알고리즘은 컴퓨터 아키텍처에 의존합니까?

알고리즘이 컴퓨터 아키텍처와 독립적이라는 어딘가를 읽었습니다 (어떤 책인지 잊었습니다). 어떤 사람들은 알고리즘 자체가 계산 (기계?)이라고 말합니까?

반면 병렬 프로그래밍에 관한 책은 병렬 알고리즘에 관한 장을 가지고 있습니다. 병렬 알고리즘이 병렬 아키텍처에 의존하는 것처럼 보입니까?

큰 그림이 그립다 고 생각합니까? 감사.

알고리즘은 특정 문제를 해결하기 위해 수행되는 일련의 단계입니다. 문제를 해결하기위한 레시피. "프로그램"은 물론 동일한 작업을 수행합니다. "알고리즘"을 사용하여 특정 기계 설계, 프로그래밍 언어 등에 독립적 인 "일반화 된"또는 "일반적으로 적용 가능한"레시피를 제안합니다.

알고리즘은 일반적으로 사용되지만 존재하는 일부 기능에 여전히 의존 할 수 있습니다. 예를 들어 "동시 알고리즘"은 서로 다른 프로그램이 동시에 실행되도록하는 메커니즘이 있는지에 따라 다릅니다. "분산 알고리즘"은 협력 그룹에 둘 이상의 시스템이 있고 이들 사이에 네트워크 또는 다른 통신 체계가있을 수 있습니다. 마찬가지로 "병렬 알고리즘"은 여러 처리 장치 (잠재적으로 많은 수의 처리 장치)와 여러 처리 장치가있을 때 공통적 인 통신 기능이있을 때 실행되도록 설계된 알고리즘입니다. 컴퓨터가 하나뿐이거나 CPU가 하나 뿐인 경우에도 "병렬 알고리즘"을 실행할 수 있지만 트래픽 엔지니어가있는 방식에는 그리 흥미롭지 않습니다.

알고리즘은 컴퓨터 아키텍처와 독립적입니다. 알고리즘이 문제를 해결하는 일련의 프로세스를 정의하기 때문입니다. 아키텍처에 관계없이 정렬 알고리즘은 항상 정렬됩니다. 일부 아키텍처에서는 갑자기 3D 도면을 렌더링하지 않습니다.

당신이 그것에 대해 생각하면, 이것은 실제로 직관적입니다. Chrome (단지 알고리즘 모음)은 모든 아키텍처 용으로 컴파일 된 웹 브라우저입니다. 일부 아키텍처에서는 갑자기 장치 드라이버가되지 않습니다.

그러나 알고리즘 실행 속도는 아키텍처에 따라 다릅니다. 또한 일부 알고리즘은 아키텍처에 따라 다른 알고리즘보다 빠르게 작동합니다.

당신이 그것에 대해 생각하면, 이것은 또한 실제로 직관적입니다. 알고리즘이 주어지면 하드웨어 설계자가 항상 해당 알고리즘의 속도를 높이는 아키텍처를 설계 할 수 있습니다. 이것이 3D 가속 그래픽 카드 및 비트 코인 채굴 기 가속기와 같은 것들이있는 이유 중 하나입니다.

사람들이 병렬 알고리즘에 대해 이야기 할 때 병렬 아키텍처에서 더 빠르게 작동 할 수있는 알고리즘에 대해 이야기하고 있습니다. 병렬 아키텍처로 개선되지 않은 많은 알고리즘이 있습니다. 따라서 병렬로 잘 작동하는 동일한 문제에 대한 새로운 알고리즘을 식별하는 것이 활발한 연구 분야입니다.

그러나이 알고리즘은 여전히 ​​똑같은 일을합니다. 아키텍처는 자신이하는 일을 변경하지 않습니다.

"병렬 알고리즘이 병렬 아키텍처에 의존하는 것 같습니까?"

제 생각에는 대답은 간단합니다 : 아니오. 일반 나는 속성을 얻는다

• 병행
• 단어 크기 (암시 적 리소스 제한)

하드웨어 아키텍처를 생각할 때.

병렬 처리를 참조하면 병렬 알고리즘을 일괄 계산하고 병렬 아치를 직렬로 작동시켜 알고리즘에 의존하지 않도록 할 수 있습니다. 단어 크기는 숫자 안정성에 문제가 될 수 있지만 알고리즘 자체에는 문제가되지 않습니다. 64 비트와 같은 리소스 제한은 2 ^ 64 개의 다른 숫자 만 설명 할 수 있지만 문제가 될 수 있지만 어쨌든 요소는 제한적입니다.

물론 일부 확장 된 명령어 세트에 의존하는 일부 알고리즘이있을 수 있지만 최소한 기본 수학으로 모든 것을 설명 할 수 있습니다.

예를 들어, 양자 컴퓨팅의 경우 일부 Big-O 값이 변경 될 수 있습니다.

"알고리즘은 컴퓨터 아키텍처와 독립적입니다"

더 이상 사실이 아닙니다.

알고리즘은 컴퓨터 아키텍처에 의존하지 않지만 특정 알고리즘을 실행하는 효율성은 아키텍처에 달려 있습니다. 어떤 Turing Complete 기계는 다른 Turing Complete 기계를 에뮬레이트 할 수 있지만 어떤 기계는 다른 기계보다 낫습니다.

동시 알고리즘의 의미는 알고리즘이 잘 작동하거나 머신의 동시성을 활용할 수 있다는 것입니다. 잠금이 덜 필요하기 때문에 동시 머신을 위해 특별히 설계되지 않은 알고리즘에 의해 필요할 수도 있고 아마도 알고리즘은 기계의 최대 성능을 사용하기 위해 나누기와 정복을 효과적으로 사용합니다. 비 동시 머신에서 알고리즘을 실행하는 것은 여전히 ​​가능하지만 효율적이지 않거나 올바르게 수행하기 위해 추가 잠금이 필요할 수 있습니다.

캐싱을 최적화하는 캐시 친화적 알고리즘과 같은 특정 아키텍처의 단점을 활용하도록 설계된 알고리즘도 있습니다. 이러한 알고리즘은 알고리즘이 가정하는 방식을 캐시하지 않는 시스템에서는 효율성이 떨어질 수 있습니다.

이론적으로 알고리즘은 아키텍처와 완전히 독립적입니다. 단일 이슈 타임 슬라이스 시스템에서 항상 병렬 아키텍처를 에뮬레이션 할 수 있습니다. 아키텍처가 전혀없는 알고리즘에 대해 추론 할 수 있습니다 . 크 누스의 책은 가상의 건축물을 사용합니다.

실제로 캐시 하드웨어 및 동기화 프리미티브의 사용을 최적화하여 동일한 "O"복잡성에 대해 더 나은 런타임을 달성하려는 알고리즘이 있습니다.

예, 아니오 충족하려는 제약 조건 과 알고리즘을 실행하는 데 필요한 사전 조건 에 따라 다릅니다 .

이상적으로 알고리즘은 단계별로 무언가를 수행하는 방법을 정의 하는 추상적 인 레시피 입니다. 알고리즘은 재현성 및 나중에 자동화라는 목표로 정의되었습니다. 알고리즘은 람다 미적분에서 유래하므로 왜 그런 방식으로 만들어 졌는지 쉽게 알 수 있습니다. 이 정의는 일반적인 것이지만 최신 알고리즘은 비 순차적 (동시 알고리즘과 같은 단계별가 아닌 또는 통일을 사용하는 것과 같은 논리적 알고리즘), 비선형 (확률 적 알고리즘) 또는 명백하게 이상 할 수 있습니다 (양자화) 알고리즘),하지만 나는 그것을 전달할 것이다.

따라서 이상적으로 알고리즘은 하드웨어를 고려하지 않고 가능한 한 추상적이어야합니다.

그러나 다른 시스템과 마찬가지로 일관성있는 시스템을 얻을뿐만 아니라 시간을 확보하기 위해 몇 가지 공리 를 정의해야합니다 . 예를 들어, 대부분의 알고리즘은 최소한 내재적으로 Von-Neumann 머신에 정의되어 있다고 가정합니다. 그렇지 않은 경우, 실행해야하는 시스템의 각 부분을 명시 적으로 정의해야합니다 (이것은 레시피를 재생하는 데 필요하므로 일종의 전제 조건). 또한 알고리즘은 종종 완전히 정의하지 않고 write ()와 같은 일반적인 명령을 사용합니다.

알고리즘이 하드웨어 아키텍처와 다르지 않은 또 다른 이유는 몇 가지 제약 조건을 충족해야 할 때 입니다.

임베디드 시스템에서 작업한다고 가정하면 워크 스테이션에있는 것과 동일한 양의 리소스에 의존 할 수 없습니다. 가장 제한적인 리소스 중 하나는 아마도 메모리 일 것입니다. 그러나 대부분의 알고리즘은 메모리 복잡성 (데이터 작업에 필요한 메모리 양)이 아니라 시간 복잡성 (CPU에서의 실행 속도)을 최적화하는 경향이 있습니다. 이러한 시스템을 위해 메모리 최적화 알고리즘은 메모리 최적화 알고리즘이 실패하거나 훨씬 느리게 실행되도록 고안되었습니다. 실제로 임베디드 시스템은 메모리 효율적인 알고리즘의 유일한 대상이 아닙니다. 예를 들어, CPU 캐시를 효율적으로 사용하기 위해 처리를 조정하는 캐시를 모르는 알고리즘 이 있습니다. 또 다른 예 : 빅 데이터를위한 일부 머신 러닝 알고리즘은컴퓨터 등에서 사용할 수있는 메모리보다 훨씬 많은 양의 데이터를 처리하기위한 증분 학습 또는 코어 외부 컴퓨팅

컴퓨터의 특정 부분을 최적화하지는 않지만 하드웨어 아키텍처에 의존하는 표준 알고리즘도 있습니다. 예를 들어 정밀도가 필요한 숫자 데이터는 플로트 또는 더블 안에 저장되며 하드웨어 제한으로 인해 본질적으로 제한됩니다. 문제는 복잡한 계산으로 반올림이 발생할 수 있으며, 반올림 된 숫자에 대해 더 많은 계산을 수행할수록 더 많이 표류 할 수 있다는 것입니다. 이것을 치명적인 간섭 이라고합니다 . 일부 응용 프로그램은 최악의 복잡한 비용으로도 정밀한 정밀도가 필요합니다. 이러한 유형의 응용을 위해, 치명적인 간섭을 줄이거 나 제거하기 위해 계산을 최적화하는 알고리즘이 만들어졌습니다.

따라서 알고리즘 설계는 추상화와 제약 사이의 절충 일 수도 있습니다.

결국 알고리즘은 목표만큼 추상적이며 전제 조건 (아키텍처) 요구 사항 이라고 말할 수 있습니다 . 알고리즘의 목표가 구체적 일수록 하드웨어 아키텍처에 더 의존 할 것입니다.

관심을 가질만한 관련 키워드 :

• 참조의 지역
• 루프 최적화
• 루프 네스트 최적화
• 확장 가능한 지역

일반적으로 알고리즘을 수학 또는 컴퓨팅 알고리즘과 혼동해서는 안됩니다. 컴퓨팅 알고리즘을 의미한다면, 예를 들어 알고리즘은 기계 아키텍처와 독립적입니다.

위키 백과의 알고리즘 정의 :

수학 및 컴퓨터 과학 에서, 알고리즘은 수행 할 독립적 인 단계별 작업 집합입니다. 계산 , 데이터 처리 및 자동화 된 추론 을 수행하는 알고리즘이 있습니다 .

이 정의는 일부 닫힌 계산 또는 데이터 처리 작업을 나타내는 데 사용됩니다. 다시 말해, Turing Machine 에서 추상적으로 실행될 수있는 계산입니다 . 그러나 최근에는 계산 중에 외부 세계와의 입출력 통신을 포함하는 대화식 계산 이라는 개념이 수학에 있습니다.

일반적인 정의에서 알고리즘은 레시피 일뿐입니다 (명령 시퀀스). 명령어 세트 나 사용할 수있는 연산을 모르면 알고리즘을 생각할 수 없다고 생각합니다. 수학적 연산은 계산에 관한 것이며, ' 오븐 가열하기 '라는 단계를 포함하는 알고리즘은 수학적 알고리즘이 아니지만 그것을 실행하는 방법을 알고 있기 때문에 요리사에게 줄 수 있습니다.

그런 다음 X, Y, Z를 수행 할 수있는 머신을 만들 수 있습니다. 각각의 알고리즘에서 명령어로 사용할 수 있습니다. 그러나 이들이 모두 폐쇄 계산에 관한 것이라면 (실제로 비 대화식 결정 론적 디지털 소 단계 계산), 귀하의 기계가 Turing Machine과 동등 함을 증명할 수 있습니다 . 그러나 다른 유형의 계산 (값 또는 대화 형 계산을 계속 하지만 [실제로 다른 유형의 계산인지 확실하지 않음]) 또는 계산이없는 작업을 대상으로하는 경우에는 계산할 수있는 기계를 생각할 수 있습니다.

이 질문과 답변 은 알고리즘에 대한 더 넓은 관점을 얻는 데에도 흥미 롭습니다.

일반적으로 알고리즘은 "비용"을 최소화하면서 특정 문제에 맞게 설계되었습니다. 역사적으로 일반적인 알고리즘의 상대적 비용이 많은 아키텍처에서 상대적으로 비슷하다는 가정하에 많은 알고리즘이 설계되었으므로 일부 일반적인 시스템은 한 알고리즘이 다른 알고리즘보다 더 잘 실행되고 이전 알고리즘은 최악의 경우 후자보다 약간 열등합니다. 시간이 지남에 따라 그러한 가정은 예전처럼 잘 유지되지 않습니다.

예를 들어, 프로그램이 메모리에서 사물을 읽는 데 필요한 횟수는 읽을 사물의 위치보다 더 중요한 것으로 간주되었습니다. 메모리에서 서로 가까이있는 것을 읽는 것은 멀리 떨어져 있지만 터무니없이 보이지 않는 것을 읽는 것보다 다소 저렴했습니다. 그러나 주 CPU 속도가 메모리 속도를 훨씬 초과하는 속도로 증가함에 따라 액세스 시퀀스의 중요성이 크게 증가했습니다. 이전 프로그램 메모리 페치의 95 %가 L1 캐시 적중을 생성하고 후자 프로그램 메모리 페치의 대부분이 캐시 미스를 생성하는 경우 한 프로그램이 다른 프로그램보다 10 배 많은 명령을 실행하면서도 더 빠르게 실행할 수 있습니다.

또한 특정 종류의 동시성 관련 알고리즘은 한 프로세서 코어에서 메모리에 기록한 데이터가 다른 코어에서 "보일"시점에 대해 다양한 가정을합니다. 많은 프로세서는 다양한 비용으로 가시성을 보장하면서 메모리를 읽고 쓸 수있는 다양한 방법을 가지고 있습니다. 일부 알고리즘은 가시성 요구 사항을 "무료"로 충족시킬 수있는 아키텍처에서는 잘 작동하지만 이러한 보증에 필요한 지침이 비싼 다른 알고리즘에서는 제대로 작동하지 않습니다. 실제로 일부 아키텍처에서는 특정 동시성 관련 알고리즘이 실행을 단일 시간 공유 CPU 코어로 제한하여 작동하도록 보장 할 수있었습니다 (물론 동시 알고리즘 사용 시점을 잃게됩니다).

많은 답변에는 알고리즘이 아키텍처와 추상적이거나 직접적인 문자 적 ​​관계로 정의 될 수 있다는 사실이 빠져 있습니다. 알고리즘은 모호하지 않아야하지만, 다소 구체적이어야 할 여지는 여전히 남아 있습니다.

문자열을 모든 대문자로 변환하는 알고리즘은 아키텍처 독립적 인 의사 코드로 쉽게 설명 할 수 있습니다. 그러나 동시에 x86 아키텍처에서 문자열을 모두 대문자로 변환하는 알고리즘을 설명하는 데 방해가되는 것은 없습니다 . 필요한 것은 x86 어셈블리 숙제입니다. (여러분은 여전히 ​​의사 코드에서이 작업을 수행 할 수 있습니다. 해당 아키텍처와 관련된 의사 코드 일뿐입니다!) x86 아키텍처에서이 작업을 수행하는 데 문제가 있다는 사실만으로 더 이상이를 해결하는 알고리즘이 없다는 의미는 아닙니다.

알고리즘이 해결하도록 정의 된 문제에 따라 다릅니다. 알고리즘이 해결하는 문제가 아키텍처와 무관 한 경우 알고리즘은 아키텍처와 무관합니다 (알고리즘을 설명하거나 구성하는 방식으로 실행이 중단되지 않는다고 가정). 문제는 이론적이거나 칠판 문제이거나 매우 구체적인 아키텍처 측면에서 발생할 수 있습니다. 후자의 경우 알고리즘은 해당 아키텍처로 작업하는 것으로 제한됩니다.

알고리즘 은 일련의 단계입니다. 그들은 그것들을 실행하는 것에 의존하지 않습니다.

그러나 알고리즘 의 시간 복잡성 은 알고리즘 을 실행하는 대상에 따라 달라질 수 있습니다 . 이것이 알고리즘의 상세한 분석이 랜덤 액세스 머신 과 같은 "계산 모델"을 요구하는 이유 입니다 .
메모리에 무작위로 액세스 할 수 있는지 여부는 알고리즘을 실행하는 데 걸리는 시간에 영향을 미치며 대부분의 알고리즘은이 경우를 가정하지만 실제로 대부분의 아키텍처는이 조건을 만족하지 않습니다.

문제의 상황에 따라 다릅니다. 알고리즘은 문제를 해결하기위한 단계 모음입니다. 이 문제의 맥락은 이론적으로 무엇이든 될 수 있습니다. 그러므로 문제를 해결하는 알고리즘은 문자 그대로 우리가 상상할 수있는 우주의 모든 것에 의존 할 수 있습니다. 예를 들어 설명하겠습니다. 당신에게 임무가 주어 졌다고 가정 해 봅시다.

멀티 코어를 사용할 수있을 때로드를 여러 코어에 분배하는 알고리즘을 구성하십시오.

이제 알고리즘이 아키텍처에 종속적 일지 상상할 수 있습니까? 물론 그렇습니다 .