diff options
| -rw-r--r-- | docs/design/029-past-one-node.md | 10 |
1 files changed, 8 insertions, 2 deletions
diff --git a/docs/design/029-past-one-node.md b/docs/design/029-past-one-node.md index d4eb13c..286485e 100644 --- a/docs/design/029-past-one-node.md +++ b/docs/design/029-past-one-node.md @@ -286,6 +286,8 @@ C의 속도로 컴파일하기 쉬운 쪽**이어야 한다. 61–183배의 절� - 런타임은 메시지마다 `pure_list_read`로 행을 트리로 다시 짓는다. - 재지 않은 것: `pure-serve`에서 링크의 레코드를 호스트의 버퍼로 옮기는 복사. 2. **디스크 열 B+트리 리프 = 실행 배열(복사 0): 트리의 순서로 찾을 때만 값이 없다.** + - 전제부터 고친다. 리스트에는 오늘 디스크의 리프가 없다. 090의 트리는 메모리에 있고, 디스크에서 리스트는 이미지와 로그다(아래 3). + 그래서 여기서 잰 복사 0은 메모리 쪽의 리프다. 리프를 디스크의 단위로 만드는 것은 아래의 열린 질문이다. - 앞의 stored_flat은 `ranges`를 트리 밖 배열로 복사했다. 009가 금하는 것이라 사다리에서 뺐고 비교로만 남긴다. - 복사 없이 트리가 둔 자리에서 읽으면 이렇다(기계 명령/점). | 단 | 기계 명령 | 그 위의 shared | @@ -295,8 +297,12 @@ C의 속도로 컴파일하기 쉬운 쪽**이어야 한다. 61–183배의 절� | 리프를 트리의 꼴대로 바로 | 7,135 | 1,576 | | 트리의 순서로 찾기 | 6,137 | 578 | - 위치로 반씩 나누는 탐색은 탐침마다 트리를 내려간다(탐침 하나에 약 78). 트리의 순서로 찾으면 그것이 사라진다. 안쪽 노드마다 자식을 - 그 첫 항목의 start로 고르고(리프를 그 자리에서 읽는다), 리프 안에서 반씩 나눈다. 그러면 복사판과 2.5% 안이다(사이클은 24% 더). - 끝에서 끝으로는 602, 같은 페이로드를 받는 Vega의 2.5배다. + 그 첫 항목의 start로 고르고(리프를 그 자리에서 읽는다), 리프 안에서 반씩 나눈다. 그러면 기계 명령은 복사판과 2.5% 안이고, 사이클은 + 24% 더 든다(388 대 312, 포인터를 따라가는 값). 끝에서 끝으로는 602에 사이클 368(복사판 592에 292)이고, 같은 페이로드를 받는 Vega의 + 2.5배(사이클 4.1배)다. + - **이 단은 내보낸 것이 아니라 다른 프로그램이다.** 앱의 `range()`는 자리를 반씩 나누고, 이 단은 첫 항목의 start로 내려간다. 예산도 + 반복마다가 아니라 부름 하나에 한 번 매긴다(점마다 약 11번 덜 매겨 비교에 조금 유리하다). 앱을 키가 있는 리스트와 seek로 바꾸고 + "start로 정렬됨"이 서야만 이 수가 성립한다. 내보내기만으로는 1,576이다. - 그러려면 `ranges`가 start로 정렬되어 있어야 한다. 데이터는 그렇고, start를 키로 선언한 리스트와 그 seek라면 저장소가 그것을 지킨다. 앱이 손으로 쓴 이분 탐색은 트리가 이미 든 색인을 다시 짓는 것이다. 이것도 겹친 계층이다. 3. **커밋 구간 = 복제 레코드 = 팔로워 바이트: 파일로는 지난다(046). 그 파일이 리프와 다른 모양이다.** |