kiến thức [Event Tặng Title] Concurrency/multi-threading in the nut shell

sirhung1993 · 23/11/21

thuyduong2007 đã nói:
Mình hỏi thật bạn có hiểu rõ cái bạn đang nói không vậy? nói lan man quá.
1. Tóm lại bạn kết luận số stage trong pipeline càng lớn thì càng tăng khả năng concurrency là đúng hay sai?
2. Theo bạn thì tại 1 thời điểm có bao nhiêu OS thread được chạy trong pipeline?

1. Đúng, nếu ko thì người ta tạo ra pipe-line làm gì ? 1 calculation tại 1 thời điểm ? really ?
Dây chuyền lắp ráp ô tô có 50 bước, thì tại 1 thời điểm, bao nhiêu chiếc ô tô đang được lắp ? Nếu bác kêu 1 thì thôi, dẹp pipe-line đi.

2. OS-thread là cách OS trừu tượng hóa phần cứng, như mình đã nói từ đầu bài. Code muốn optimize CPU-cycle -> xin thêm thread từ OS ( default limit 600 threads/process) -> còn lúc instruction được fetch vào PC thì mới qua scope của hardware-thread hoặc core vật lý như bác nói. Nhưng trước đó instruction muốn vào hardware, nó còn phải được OS check qua đủ thứ ràng buộc. ( hoặc bác code nhúng trực tiếp = C/C++ không thông qua OS)

Fire Of Heart · 23/11/21

Topic này hơi hard với tôi rồi, chắc cuối tuần rảnh phải đọc lại về OS với hardware

Btw lâu lâu mới thấy thảo luận hăng thế

bribnt · 23/11/21

Kurt Godel đã nói:
Nhưng nếu xét về mặt vật lý gia tốc, state electron dịch chuyển thì 1 tập lệnh lại chỉ thể hiện 1 state. Nghĩa là người ta vẫn chứng minh được rằng 1 core/1 phép tính/1 thời điểm.

Bạn phải đọc lại về vi kiến trúc của CPU thì mới rõ được phần này.
Nói nôm na là trong CPU với mỗi stage của pipeline thì đều thực hiện được cùng lúc nhiều việc.

Lấy lại cái hình về Zen 3 mới post lần trước:

Trong 1 chu kỳ có thể decode 4 lệnh
Dispatch được 6 lệnh vào bộ renamer
Có 6 bộ scheduler để gửi ops đến các EU
Có đến 14 EU để thực thi các phép tính toán với đủ loại: số học, dấu chấm động, memory, ...

Cái khả năng thực hiện nhiều việc cùng lúc này là đơn giản do nhồi nhiều component thôi, chứ chả phải ma thuật gì cả.

Cái khái niệm thread (OS hay hardware) chỉ là khái niệm bậc cao, còn nhìn xuống dưới nữa thì bên trong là rất nhiều tác vụ khác.

Kurt Godel · 23/11/21

bribnt đã nói:
Bạn phải đọc lại về vi kiến trúc của CPU thì mới rõ được phần này.
Nói nôm na là trong CPU với mỗi stage của pipeline thì đều thực hiện được cùng lúc nhiều việc.

Lấy lại cái hình về Zen 3 mới post lần trước:

Trong 1 chu kỳ có thể decode 4 lệnh

Dispatch được 6 lệnh vào bộ renamer

Có đến 14 EU để thực thi các phép tính toán với đủ loại: số học, dấu chấm động, memory, ...

Cái khả năng thực hiện nhiều việc cùng lúc này là đơn giản do nhồi nhiều component thôi, chứ chả phải ma thuật gì cả.

Cái khái niệm thread (OS hay hardware) chỉ là khái niệm bậc cao, còn nhìn xuống dưới nữa thì bên trong là rất nhiều tác vụ khác.

Tôi đọc từ lâu rồi, cái tôi đang nói là chứng minh cái gọi là "concurrent time" của 2 phép tính ở mức lượng tử. Nghĩa là phương sai = 0.

với hyperthread thì 1 clock cycle sẽ có thể nhiều hơn 1 phép tính. Nhưng hiện thì chưa thể chứng minh được thời điểm có thể là 1/3 tỷ giây nó xảy ra như thế nào trong gia tốc vũ trụ, lấy cái gì làm hệ quy chiếu cho nó để chứng minh 2 phép tính xảy ra cùng một thời điểm. mình chưa chính minh được cái này nên bản thân ở giữa hai chiều nhận định. Có thể là bạn đúng tôi sai, tôi đúng bạn sai hoặc chưa chắc nó tồn tại hay không để khẳng định.

P/s: ngày xưa tính chọn chủ đề "performance for a computing system" để làm luận án tốt nghiệp mà cứ bị cuốn vào cái thuyết thời gian đồng thời tính bằng 1/tỷ giây nó tồn tại hay không tồn tại nên bỏ chủ để này.

thuyduong2007 · 23/11/21

thuyduong2007 đã nói:
2. Theo bạn thì tại 1 thời điểm có bao nhiêu OS thread được chạy trong pipeline?

sirhung1993 đã nói:
2. OS-thread là cách OS trừu tượng hóa phần cứng, như mình đã nói từ đầu bài. Code muốn optimize CPU-cycle -> xin thêm thread từ OS ( default limit 600 threads/process) -> còn lúc instruction được fetch vào PC thì mới qua scope của hardware-thread hoặc core vật lý như bác nói. Nhưng trước đó instruction muốn vào hardware, nó còn phải được OS check qua đủ thứ ràng buộc. ( hoặc bác code nhúng trực tiếp = C/C++ không thông qua OS)

Trả lời đúng trọng tâm câu hỏi đi, trả lời lan man chỉ chứng tỏ bạn k hiểu rõ vấn đề thôi.

bribnt · 23/11/21

Kurt Godel đã nói:
Tôi đọc từ lâu rồi, cái tôi đang nói là chứng minh cái gọi là "concurrent time" của 2 phép tính ở mức lượng tử. Nghĩa là phương sai = 0.

với hyperthread thì 1 clock cycle sẽ có thể nhiều hơn 1 phép tính. Nhưng hiện thì chưa thể chứng minh được thời điểm có thể là 1/3 tỷ giây nó xảy ra như thế nào trong gia tốc vũ trụ, lấy cái gì làm hệ quy chiếu cho nó để chứng minh 2 phép tính xảy ra cùng một thời điểm. mình chưa chính minh được cái này nên bản thân ở giữa hai chiều nhận định. Có thể là bạn đúng tôi sai, tôi đúng bạn sai hoặc chưa chắc nó tồn tại hay không để khẳng định.

P/s: ngày xưa tính chọn chủ đề "performance for a computing system" để làm luận án tốt nghiệp mà cứ bị cuốn vào cái thuyết thời gian đồng thời tính bằng 1/tỷ giây nó tồn tại hay không tồn tại nên bỏ chủ để này.

Mấu chốt là ở đây: tùy theo hệ quy chiếu mốc thời gian mà khả năng đồng thời là có thể xảy ra.
Nó khác hoàn toàn với việc khẳng định rằng chỉ có 1 phép toán được thực hiện tại một thời điểm. Trong CPU 2 component là độc lập nhau, 2 sự kiện tính toán không có quan hệ nhân quả nên không có cái gì bắt buộc là chỉ có 1 được xảy ra tại một lúc nào đó.

TB: Cái vụ tính được nhiều phép tính thì không cần hyperthreading, 1 thread là đủ rồi. 2 thread thì tận dụng tốt hơn.

Kurt Godel · 23/11/21

bribnt đã nói:
Mấu chốt là ở đây: tùy theo hệ quy chiếu mốc thời gian mà khả năng đồng thời là có thể xảy ra.
Nó khác hoàn toàn với việc khẳng định rằng chỉ có 1 phép toán được thực hiện tại một thời điểm. Trong CPU 2 component là độc lập nhau, 2 sự kiện tính toán không có quan hệ nhân quả nên không có cái gì bắt buộc là chỉ có 1 được xảy ra tại một lúc nào đó.

TB: Cái vụ tính được nhiều phép tính thì không cần hyperthreading, 1 thread là đủ rồi. 2 thread thì tận dụng tốt hơn.

Trong CPU 2 component là độc lập nhau. =>Sai nhé, nó sẽ bind với nhau.
1 phép toán được thực hiện tại một thời điểm => Cho nên suy cho cùng vẫn quay lại vấn đề chứng minh sự tồn tại của chênh lệch quá nhỏ của thời gian 1/3 tỷ s. Còn lại sẽ là khái niệm về Parallelism.

Kurt Godel · 23/11/21

Mà thôi tôi chốt quan điểm cũ (tôi chưa khẳng định): 1 core/1 phép tính/1 thời điểm.
1 thời điểm ở đây có thể là 1/3 tỷ s hoặc 1/6 tỷ s tùy vào 1 clock cycle thực hiện được bao nhiêu phép tính . Nghĩa là mỗi lần xung nhịp thì sẽ có n mốc thời gian trôi qua tương đương n lần phép tính / 1 clock cycle thực hiện.

Tôi nghỉ thớt này lý do: tôi chưa chứng minh được sự tồn tại của thời gian 1/3 tỷ s hoặc 1/6 tỷ s nên tôi nghỉ vì cái lý của tôi nó chưa được chứng minh nên tôi không khẳng định được với ai.

cs_50i · 23/11/21

Khiếp thật! Thớt này lái đến tận chứng minh 1/6 tỷ s tồn tại hay không? :eek:

Chớp mắt hết 1 giây, toàn bộ người trên địa cầu cùng chớp mắt trong 1s thì xác xuất xảy ra đồng thời la bao nhiêu các fen?

Hoai cmn Linh · 23/11/21

Các thím đi sâu phần hardware nó low level quá đọc khó hiểu.
E chỉ có thắc mắc là sự khác nhau của concurrency và parallel/multi thread là gì

KimSoHyunGoddness · 24/11/21

Kurt Godel đã nói:
Mà thôi tôi chốt quan điểm cũ (tôi chưa khẳng định): 1 core/1 phép tính/1 thời điểm.
1 thời điểm ở đây có thể là 1/3 tỷ s hoặc 1/6 tỷ s tùy vào 1 clock cycle thực hiện được bao nhiêu phép tính . Nghĩa là mỗi lần xung nhịp thì sẽ có n mốc thời gian trôi qua tương đương n lần phép tính / 1 clock cycle thực hiện.

Tôi nghỉ thớt này lý do: tôi chưa chứng minh được sự tồn tại của thời gian 1/3 tỷ s hoặc 1/6 tỷ s nên tôi nghỉ vì cái lý của tôi nó chưa được chứng minh nên tôi không khẳng định được với ai.

Clone của ông nào trong bài viết này đây?

sirhung1993 · 24/11/21

sirhung1993 đã nói:
1. Đúng, nếu ko thì người ta tạo ra pipe-line làm gì ? 1 calculation tại 1 thời điểm ? really ?
Dây chuyền lắp ráp ô tô có 50 bước, thì tại 1 thời điểm, bao nhiêu chiếc ô tô đang được lắp ? Nếu bác kêu 1 thì thôi, dẹp pipe-line đi.

2. OS-thread là cách OS trừu tượng hóa phần cứng, như mình đã nói từ đầu bài. Code muốn optimize CPU-cycle -> xin thêm thread từ OS ( default limit 600 threads/process) -> còn lúc instruction được fetch vào PC thì mới qua scope của hardware-thread hoặc core vật lý như bác nói. Nhưng trước đó instruction muốn vào hardware, nó còn phải được OS check qua đủ thứ ràng buộc. ( hoặc bác code nhúng trực tiếp = C/C++ không thông qua OS)

thuyduong2007 đã nói:
Trả lời đúng trọng tâm câu hỏi đi, trả lời lan man chỉ chứng tỏ bạn k hiểu rõ vấn đề thôi.

Lan man ở đâu nhỉ ? Câu hỏi bao nhiêu OS-thread ở trong pipe-line, thì mình rep lại nó là cách OS trừu tượng hóa core/thread vật lý cho application/code thực thi.

Application chạy trên OS, từ OS mới cấp phát resource. Việc tạo OS-thread nó có ý nghĩa là app muốn xin thêm CPU-cycle hoặc có thể hiểu là tăng thêm số instruction được fetch vào hardware.

Còn hỏi bn OS-thread chạy trong pipe-line thì đó là câu hỏi không có đáp án cụ thể ? Vì không có 1 tỉ lệ cụ thể nào giữa OS-thread vs hardware ? Nó còn phụ thuộc rất nhiều vào loại application đang chạy, nếu là nặng về IO như http-call, access file như DB thì bác có xin 200 OS-thread nó cũng chưa chắc xài hết 1-2 core ( check = htop)

Ngược lại với ứng dụng nặng về tính toán floating-point đòi hỏi precision cao, thì đôi khi nó chỉ xin 16 threads -> full luôn cả 32 core cpu.

2 ví dụ trên là để minh chứng là ko có cách chính xác nào biết được bn OS-thread đang được load vào pipe-line cả.

Mình hay dùng 1 minh họa cho OS-thread vs hardware-thread như sau:

lúc application xin 16 OS-thread -> OS tăng số INSTRUCTION được fetch vào hardware tại 1 thời điểm cho application đó lên 16 instruction/cycle ( trong điều kiện cho phép)
OS lưu 1 queue các instruction muốn được fetch vào hardware -> đẩy vào PC theo các thứ tự được tính toán dựa trên các tham số như process priority / threads / available CPU-cycles.

Trả lời như thế này còn nói lan man nữa thì mình chịu 0)0

thuyduong2007 · 24/11/21

sirhung1993 đã nói:
lúc application xin 16 OS-thread -> OS tăng số INSTRUCTION được fetch vào hardware tại 1 thời điểm cho application đó lên 16 instruction/cycle ( trong điều kiện cho phép)

OS lưu 1 queue các instruction muốn được fetch vào hardware -> đẩy vào PC theo các thứ tự được tính toán dựa trên các tham số như process priority / threads / available CPU-cycles.

Bạn đang hiểu rất sai về pipeline và cách mà hardware nó vận hành.

Nếu như 1 pipeline có nhiều step, và mỗi step lại chứa instruction của các thread khác nhau vậy thì 1 core chạy được nhiều thread tại 1 thời điểm rồi, ngta còn đẻ ra multicore làm gì???
Nếu như mỗi step trong pipeline chạy 1 instruction của các thread khác nhau thì tại sao ngta lại phải giải quyết bài toán data dependency và branch predicting trong pipeline???

Mình nhắc lại pipeline có 5 step, tại 1 thời điểm có thể có 5 instruction nằm trong pipeline nhưng 5 instruction này đều nằm trong 1 thread.
Nói đến đây mà bạn vẫn k chịu hiểu thì mình sẽ không rep lại bạn nữa. Bạn cứ hiểu theo cách của bạn nhé. Thân!

sirhung1993 · 24/11/21

thuyduong2007 đã nói:
Bạn đang hiểu rất sai về pipeline và cách mà hardware nó vận hành.

Nếu như 1 pipeline có nhiều step, và mỗi step lại chứa instruction của các thread khác nhau vậy thì 1 core chạy được nhiều thread tại 1 thời điểm rồi, ngta còn đẻ ra multicore làm gì???

Nếu như mỗi step trong pipeline chạy 1 instruction của các thread khác nhau thì tại sao ngta lại phải giải quyết bài toán data dependency và branch predicting trong pipeline???

Mình nhắc lại pipeline có 5 step, tại 1 thời điểm có thể có 5 instruction nằm trong pipeline nhưng 5 instruction này đều nằm trong 1 thread.
Nói đến đây mà bạn vẫn k chịu hiểu thì mình sẽ không rep lại bạn nữa. Bạn cứ hiểu theo cách của bạn nhé. Thân!

Hình như bác muốn vặn cái ý này của mình ở đầu thớt

Tức là với pipe-line có 5 stages, thì đôi khi 1 số stage bị block bởi việc access-memory, thì 1 core vẫn chạy ở những stages khác.
Về lý thuyết nó có thể chạy 1 lúc 5 tasks.

Vậy thì bác phải scope lại cái 5 instruction của 1 hardware-thread.

Còn về phần 5 instruction cái đó có phải 1 OS-thread hay không thì tôi không chắc, vì tôi có thể code cho các thread-scope không dependency về mặt memory (pure function) -> về lý thuyết nó có thể fetch instruction ko depend lẫn nhau hoặc không tốn CPU-cycle 1 cách concurrent / hardware-thread.

Nếu như scope vấn đề lại ntn thì có phải nó vẫn đạt được tiêu chí là concurrent ?

zulu · 24/11/21

Fire Of Heart đã nói:
Đây đây, về pipeline thì mời các thím đọc slide này.
http://www.cit.ctu.edu.vn/~dtnghi/cod/ch6.pdf

Tôi định tóm tắt mà thấy cái slide này nó chi tiết và đầy đủ các ý cmnr

Tài liệu ngon thế này sao hồi xưa UIT ko đưa thầnh môn cơ sở cho tất cả các ngành nghỉ.

Fire Of Heart · 24/11/21

Theo tôi đọc trong tài liệu kia thì có vẻ cái này thím @sirhung1993 nghĩ đúng mà nhỉ?

Fire Of Heart · 24/11/21

thuyduong2007 đã nói:
Bạn đang hiểu rất sai về pipeline và cách mà hardware nó vận hành.

Nếu như 1 pipeline có nhiều step, và mỗi step lại chứa instruction của các thread khác nhau vậy thì 1 core chạy được nhiều thread tại 1 thời điểm rồi, ngta còn đẻ ra multicore làm gì???

Nếu như mỗi step trong pipeline chạy 1 instruction của các thread khác nhau thì tại sao ngta lại phải giải quyết bài toán data dependency và branch predicting trong pipeline???

Mình nhắc lại pipeline có 5 step, tại 1 thời điểm có thể có 5 instruction nằm trong pipeline nhưng 5 instruction này đều nằm trong 1 thread.
Nói đến đây mà bạn vẫn k chịu hiểu thì mình sẽ không rep lại bạn nữa. Bạn cứ hiểu theo cách của bạn nhé. Thân!

Cái chỗ số 1, pipeline và multicore khác nhau hoàn toàn thím nhé.

Fire Of Heart · 24/11/21

Kurt Godel đã nói:
Mà thôi tôi chốt quan điểm cũ (tôi chưa khẳng định): 1 core/1 phép tính/1 thời điểm.
1 thời điểm ở đây có thể là 1/3 tỷ s hoặc 1/6 tỷ s tùy vào 1 clock cycle thực hiện được bao nhiêu phép tính . Nghĩa là mỗi lần xung nhịp thì sẽ có n mốc thời gian trôi qua tương đương n lần phép tính / 1 clock cycle thực hiện.

Tôi nghỉ thớt này lý do: tôi chưa chứng minh được sự tồn tại của thời gian 1/3 tỷ s hoặc 1/6 tỷ s nên tôi nghỉ vì cái lý của tôi nó chưa được chứng minh nên tôi không khẳng định được với ai.

Mình ko hiểu sao thím phải đi chứng minh cái này, có thể mình đang ko hiểu điều thím nói, nhưng ng ta định nghĩa:
1 giây là khoảng thời gian bằng 9 192 631 770 lần chu kỳ của bức xạ điện từ phát ra bởi nguyên tử Cs133 khi thay đổi trạng thái giữa hai mức năng lượng đáy siêu tinh vi. (wiki).
Vậy thì 1/6 tỷ giây của thím nó đâu đó là khoảng thời gian 1.5 chu kỳ còn gì?

Chưa hiểu điều thím đang băn khoăn ở đây là gì?

thuyduong2007 · 24/11/21

Fire Of Heart đã nói:
Cái chỗ số 1, pipeline và multicore khác nhau hoàn toàn thím nhé.

Thì nó khác nhau mà. Nhưng ông kia đang hiểu nó giống nhau nên t mới hỏi nếu nó giống nhau thì sao phải sinh ra 2 cái làm gì, kiểu vậy.
Nói chung ông kia đang hiểu nhầm pipeline với multicore. :beat_brick:

Tóm lại pipeline giúp tăng throughput, nhưng đồng thời làm tăng latency. Chứ chả liên quan gì đến concurrency cả.

Fire Of Heart · 24/11/21

các thím nghĩ sao về concurrency trên máy chỉ có 1 core?

kiến thức [Event Tặng Title] Concurrency/multi-threading in the nut shell

Người qua đường

277;67;6824839

Đã tốn tiền

Junior Member

Member

Đã tốn tiền

Junior Member

Junior Member

bố Bơ

Member

Member

Người qua đường

Member

Người qua đường

Member

277;67;6824839

277;67;6824839

277;67;6824839

Member

277;67;6824839

Chủ đề tương tự

Thống kê chủ đề

Chia sẻ trang này