추상 위키백과/업데이트/2021-06-17

◀

추상 위키백과 업데이트

▶

지난주 업데이트를 놓친 것에 대해 사과드립니다. 시간은 평소보다 더 바쁩니다.

함수의 여러 구현을 허용하는 이유는 무엇인가요?

오늘 주제로 들어가기 전에 두 가지를 간단히 상기하고자 합니다:

우리의 첫 근무 시간은 2021년 6월 22일 화요일 16:00 UTC입니다. 텔레그램 채널과 Libera.Chat IRC 채널 #wikipedia-abstract^접속.에서 진행됩니다.
2021년 6월 24일 목요일, 우리는 북극권 매듭 회의(Arctic Knot conference)에서 발표 할 것입니다. 커뮤니티 회원 마히르 모셰드(Mahir Morshed)는 15:00 UTC에 추상 위키백과에서 사용할 사전식 데이터를 준비하는 방법에 대해 발표하고, 데니(Denny)는 16:00 UTC에 추상 위키백과와 위키함수 일반에 대해 발표할 예정입니다.

위키함수의 핵심 모델은 함수를 중심으로 합니다 . 모든 함수는 여러 구현을 가질 수 있습니다. 함수의 모든 구현은 동일한 입력에 대해 동일한 결과를 반환해야합니다.

질문 할 수 있습니다: 왜? 모두 동일하게 수행되는 여러 구현의 요점은 무엇인가요?

이에 대한 몇 가지 답변이 있습니다. 예를 들어, 많은 함수의 경우 다른 구현에서 사용할 수있는 다른 알고리즘이 존재합니다. 컴퓨터 과학 수업의 전통적인 예는 정렬 기능입니다: 정렬 함수는 정렬 할 요소 목록 (즉, 특정 선형 순서로 가져옴)이라는 두 개의 인수를 사용하고, 두 개의 요소가 주어지면 어떤 요소가 먼저 가야하는지 알려주는 비교 연산자가 있습니다. 정렬 기능을 구현하는 데 사용할 수 있는 다양한 정렬 알고리즘이 있습니다. 다른 분류 알고리즘의 특히 흥미로운 시각화는 민속 춤의 형태에서 찾을 수 있습니다.

정렬 함수를 호출하는 사람은 작동하고 정확하며 충분히 빠르게 반환되는 한 사용중인 알고리즘에 대해 별로 신경 쓰지 않는 경우가 많습니다. 그러나 다른 알고리즘을 구현하면 서비스가 다른 알고리즘을 실행하고 런타임 동작을 서로 비교할 수 있습니다. 다른 알고리즘은 종종 다른 양의 메모리 또는 계산주기를 필요로합니다. 다양한 구현의 런타임 동작을 추적하면 결국 함수 오케스트레이터가 주어진 입력과 주어진 순간에 가장 효율적인 구현을 예측하고 선택할 수 있습니다. 예비 컴퓨팅 주기를 사용할 수 있는 경우 이러한 구현의 다른 동작에 대해 자세히 알아보기 위해 다른 입력으로 일부 구현을 실행할 수도 있습니다.

여러 구현을 허용하는 한 가지 이점은 위키함수를 편집 할 때 충돌 가능성을 줄인다는 것입니다. 기여자가 다른 구현을 시도하고 싶을 때 더 효율적일 수 있다고 생각한다면 그렇게하고 구현을 시스템에 제출하는 것을 환영합니다. 서로 다른 프로그래밍 언어와 상대적인 장점 및 특성에 대한 잘 알려진 주장이 위키함수에 넘칠 필요가 없습니다. 누구나 좋아하는 프로그래밍 언어로 자신이 좋아하는 알고리즘의 구현을 제공 할 수 있으며 시스템이 처리합니다. 올바른 구현을 자동으로 검증, 테스트 및 선택합니다.

여러 구현의 또 다른 이점은 서로에 대해 엄격하게 테스트 할 수 있다는 것입니다. 물론, 초기 정확성 검사 (또한 런타임 메타 데이터 수집을 시작하기 위해)를 위해 사용자가 작성한 테스터 모음이 있습니다. 그러나 함수의 독립 구현이 여러 개 있는 경우 추가 입력을 종합적으로 생성하거나 다른 구현에 대해 실제 사용자 제출 함수 실행을 실행하여 실행에 대한 더 많은 메타 데이터를 수집 할 수 있습니다. 여러 가지 구현이 있으므로 이를 사용하여 서로 다른 구현을 교차 검증하고 서로 다른 구현의 결과를 비교하며 커뮤니티에 발생하는 불일치를 버블링 할 수 있습니다.

다양한 알고리즘을 구현하는 것 외에도 다른 프로그래밍 언어로 구현할 수 있을 것으로 기대합니다. 서로 다른 프로그래밍 언어의 구현은 서로 다른 알고리즘이 유용한 것과 같은 이유로 유용합니다. 즉, 서로 교차 검증할 수 있고 주어진 함수 호출에 대해 가장 효율적인 구현을 선택할 수 있습니다. 그러나 위키데이터 함수 평가자의 다른 구성에서 실행할 수 있다는 추가적인 이점이 있습니다. 그게 무슨 뜻인가요?

위키함수에 구현을 추가하기 위해 다양한 프로그래밍 언어를 지원할 계획이지만 실제로 제품에서 모든 평가자를 실행할 계획은 없습니다. 이는 몇 가지 이유 때문입니다. 이러한 모든 평가자를 계속 실행하고 최신 상태로 유지하는 데 드는 유지 관리 비용은 심각할 수 있습니다. 우리가 지원하는 프로그래밍 언어가 많을수록 재단이나 커뮤니티가 이러한 언어의 런타임에서 버그나 보안 문제에 노출 될 가능성이 높아집니다. 그리고 5~6개의 프로그래밍 언어를 넘어 서면 투자 수익이 크게 감소 할 가능성이 있습니다. 그렇다면 제품에서 실행할 계획이 없는 프로그래밍 구현의 요점은 무엇인가요?

우리는 위키미디어 재단이 운영하는 것과는 독립적으로 많은 기능 평가자가 있는 위키 기능 주변의 생태계를 계획하고 있음을 기억하세요. 우리는 평가자가 스마트 폰에서 앱으로 사용 가능하고, 가정에서 자신의 컴퓨터와 브라우저 또는 클라우드에서 평가자를 사용할 수 있고, 제3자가 시스템 내에 특정 기능에 대한 평가자를 포함하도록 하기를 바랍니다. 평가자의 피어 투 피어 네트워크가 자원과 결과를 교환하도록합니다. 이러한 컨텍스트 내에서 백엔드는 사용 사례에 유리하거나 특정 프로그래밍 언어에 제한되거나 열정적이기 때문에 위키함수에서 지원하는 프로그래밍 언어와 다른 프로그래밍 언어 집합을 지원하도록 선택할 수 있습니다. 특히 서드 파티 앱의 시스템에 내장된 위키함수 기능을 실행하는 경우 내장 앱과 동일한 언어로 이러한 기능을 실행하기 위해 상당한 성능 향상을 쉽게 제공 할 수 있습니다.

다른 프로그래밍 언어로 구현할 때의 또 다른 장점은 평가자가 갑자기 중단되어야하는 경우입니다. 보안 문제가 보고되었지만 아직 수정되지 않았거나 특정 평가자의 리소스 비용이 문제가있는 방식으로 개발 되었기 때문에 해당 평가자를 중단하고 다른 프로그래밍 언어 집합을 실행하도록 구성을 변경할 수 있습니다. 이는 서비스를 사용하는 사람들을 방해하지 않고 위키함수의 작동을 지원하는 방법에 많은 유연성을 제공합니다.

함수의 구현은 또한 함수 구성으로 제공 될 수 있습니다: 프로그래밍 언어로 제공되는 코드 대신 구성은 주어진 함수를 구현하기 위해 위키함수에서 기존 함수를 가져 와서 함께 중첩합니다. 예를 들면 다음과 같습니다: 단어의 두 번째 문자를 반환하는 second 함수를 구현한다고 가정 해 보겠습니다. 단어의 첫 글자를 반환하는 함수 first와 단어의 첫 글자를 잘라 내고 나머지를 반환하는 함수 tail이 이미 있다고 가정합니다. second (w)는 first (tail (w))로 구현 될 수 있습니다. 즉, 첫 글자를 자른 후 결과의 첫 글자입니다. 함수 구성에 대해서는 다음 시간에 더 자세히 설명하겠습니다.

컴포지션은 코드에서 모든 함수를 구현하거나 내장 할 필요가 없다는 장점이 있지만 이러한 함수를 평가할 수 있습니다. 백엔드는 함수 호출을 올바르게 연결하고 요청 된 결과에 도달 할 때까지 한 함수의 결과를 다음 함수로 파이프합니다. 이는 다른 프로그래밍 언어 세트를 제공하거나 특정 프로그래밍 언어에 초점을 맞추는 서드 파티 평가자에게 특히 유용 할 수 있습니다. 로컬 구현 없이도 많은 함수 세트를 사용할 수 있습니다.

우리는 컴포지션이 일반적으로 코드 실행에 비해 경쟁력이 떨어지는 성능을 제공 할 것으로 기대합니다. 우리의 메타 데이터는 특히 리소스 집약적인 함수 호출을 정확히 찾아 낼 수 있습니다. 우리는 이러한 결과를 위키에 표시하여 보다 효율적인 구현이 가장 큰 영향을 미칠 수있는 커뮤니티를 강조 할 계획입니다. 예를 들어, 기여자가 웹어셈블리(WebAssembly)로 함수를 이식한 덕분에 얼마나 많은 CPU 사이클이 절약되었는지 확인할 수있는 기능을 기대하고 있습니다.

함수 구성에 대한 한 가지 흥미로운 접근 방식은 구성에 참여하는 모든 함수에 대해 특정 프로그래밍 언어로 된 코드가 있는 경우 해당 프로그래밍 언어로 구성된 함수에 대한 코드를 합성하고 컴파일 할 수 있다는 것입니다. 이로 인해 두 개의 서로 다른 프로그래밍 언어가 일부 참여 함수에 대해 가장 효율적인 구현을 제공하지만 실제 함수 호출은 새로운 합성 결과에서 훨씬 더 효율적으로 실행되는 상황으로 이어질 수 있습니다.

마지막으로 캐싱도 있습니다. 구성된 함수의 중첩된 호출을 포함한 모든 함수 호출은 캐시되고 재사용 될 수 있습니다. 이 캐시는 모든 프로젝트에서 공유되며 상당한 속도 향상을 제공합니다: 결국, 특정 계산이 다른 문서보다 훨씬 더 인기가 있을 가능성이 높습니다. 이는 특정 문서가 주어진 시간에 다른 문서보다 훨씬 더 인기있는 것과 비슷합니다. 또한 위키백과가 페이지를 읽고 싶을 때마다 페이지를 다시 렌더링하는 대신 캐시에 보관하여 엄청난 양의 CPU주기를 절약하는 것처럼, 함수 호출과 그 결과의 캐시를 유지함으로써 유사한 이점을 얻을 수 있습니다.

요약하면: 한 함수에 대해 여러 가지 구현을 하면 함수를 계획하고 실행하는 방법에 더 많은 유연성을 제공하여 잠재적으로 리소스를 절약할 수 있을뿐만 아니라 다음과 같은 이유로 시스템 전체의 정확성에 대해 더 높은 신뢰도를 얻을 수 있습니다. 다른 구현의 교차 유효성 검사를 수행하고 위키함수를 편집할 때 충돌 가능성을 줄입니다.

우리는 실제로 이것이 어떻게 진행될 것인가를 보고 매우 궁금합니다. 위의 몇 단락에서는 백엔드에서 많은 현명한 개발 작업이 필요한 아이디어에 대해 설명하며 각 아이디어가 얼마나 잘 수행 될지 알 수 없습니다. 우리는 더 많은 아이디어 (아마도 여러분이? 아마도 연구 실험실에서 나왔을까요?)를 발견하고 여기에서 스케치 한 아이디어 중 일부가 작동하지 않는다는 것을 발견 할 것으로 기대합니다. 우리는 위에서 설명한 모든 것을 구현할 것을 약속하지 않습니다. 좋은 점은 이러한 아이디어 중 많은 부분이 궁극적으로 최적화라는 것입니다: 이 모든 것의 단순한 버전이라도 올바른 결과를 제공해야합니다. 그러나 더 현명한 접근 방식은 엄청난 양의 리소스를 절약하고 프로젝트의 잠재력을 최대한으로 확장 할 수 있게합니다.

다른 프로젝트와 마찬가지로 우리는 데이터와 메타 데이터를 게시할 계획이며, 이러한 흥미롭고 어려운 과제를 해결하는 데 도움이 되도록 학계와 산업계, 애호가, 독립적인 개발자 및 연구원의 외부 조직을 초대합니다.

다시 한 번 알림: 첫 번째 근무 시간은 2021년 6월 22일 화요일 16:00 UTC에 "텔레그램" 채널과 "리베라 챗(Libera.Chat) IRC" 채널 #wikipedia-abstract^접속에서 예정되어 있습니다.