Cái hình minh họa không được chính xác lắm, mình nhác vẽ lại nên trích nguồn từ ông khác.
Mình có rep tương tự ở trên , tùy vào scope vs định nghĩa về multi-threading.
Idea 1 thì tùy vào định nghĩa của bác ntn là concurrency? Vì thứ tự instruction được fetch vào PC không được control hoàn toàn bởi application -> còn phụ thuộc vào OS-priority . Với mình thì việc tạo nhiều thread trên 1 process -> tăng tỉ lệ số instruction của 1 process được load vào PC -> chiếm được CPU cycle.Sorry chủ thớt nhưng mình thấy một số ý của bạn trong phần Hardware có vẻ chưa thực sự chính xác. Mình sẽ giải thích lại theo cách hiểu của mình như sau:
- CPU được tạo ra bằng cách kết nối các cổng logic. Các cổng logic này hoạt động dựa trên xung nhịp. Muốn tăng tốc độ của phần mềm thì cần giảm thời gian thực hiện 1 câu lệnh xuống bằng cách tăng xung nhịp lên. Tuy nhiên khi tăng xung nhịp thì sẽ dẫn đến tiêu hao điện năng và giảm tuổi thọ của CPU. Do đó người ta mới nghĩ ra kiến trúc pipeline để giải quyết chuyện này. Bằng cách chia nhỏ các bước trong một câu lệnh ra và các bước này sẽ có thể được làm overlap vào nhau. Thực tế nó có thể overlap không tùy tùy từng trường hợp cụ thể. Hardware nó sẽ tự xử lý để tối ưu (branch predictor). Ngoài ra thì compiler cũng giúp tăng được lượng overlap lên bằng cách reorder các câu lệnh để giải quyết một số trường hợp liên quan đến data dependency (Optimizing compiler). Điều này giúp tăng throughput tuy nhiên cũng làm tăng latency. Nó không thực sự liên quan đến khả năng concurency. Vì kể cả có chạy 1 thread duy nhất thì pipeline vẫn giúp tăng throughput.
- Kiến trúc hiện đại nó có nhiều thứ hay ho hơn.
- Đầu tiên phải kể đến là SIMD instruction. Cái này giống như thay vì cộng từng phần tử giữa 2 vector thì nó cộng nhiều phần tử trong 1 câu lệnh. 1 dạng song song nhưng tại instruction level. Anh em nào có xài numpy trong python và thắc mắc vì sao nó chạy nhanh thì 1 phần là do cái này. Ngoài ra còn do tối ưu về cache nữa.
- Tiếp theo phải kể để là hyper threading. Chắc ae đều đã nghe qua mấy cái quảng cáo dạng như 2 nhân 4 luồng. Cái này dạng như 1 core nhưng nó có ít nhất là 2 cho mỗi thanh ghi đặc biệt (vd: program counter) để giữ được context của 2 thread khác nhau. Giả sử thread1 đang chờ load data từ main memory do bị miss cache,... Thì thread2 sẽ được thực thi. Do đó nó giúp tận dụng tối đa thời gian của CPU.
Nếu như lấy luận điểm này làm gốc, thì các LLVM-based như Rust,Haskell vs Go-lang cũng ko có core thread. Vì tụi nó phải dịch về LLVM -> từ LLVM thông qua lib kernals -> machine-code
Đang nói về riêng Nodejs thớt nhé. Worker-thread không phải đẩy vào trong Nodejs core để thành muti-thread.
statement1();
statement2();statement3 giờ ơi đất hỡi ở đâu đó (tất nhiên là trong cùng 1 chương trình, cùng ngôn ngữ đó) chạy chen vào không.Cái này cực kỳ sai nhé. Không có chuyện pipeline có 5 stage thì tại 1 thời điểm có thể chạy được 5 task khác nhau. Tại vì nếu chạy 5 task cùng 1 lúc trên 1 core thì hardware cần phải có đủ resource để giữ được context của 5 task cùng 1 lúc. Nên số lượng task chạy được cùng 1 thời điểm trên 1 core chả liên quan gì đến số stage trong pipeline cả. Chủ thớt hiểu sai về pipeline cmnr,
.
Theo tôi thì multi-threading ở đây là ngta nói về mặt thread programming. Thread phải create assign handle join các thứ đc, tức là programming đx ấy mới tính là multi threading lang. Nên node ko thể gọi là multi thread.
like cho bác, " 1 core có 2 bộ phận chính là Program Counter(PC) và Arithmetic Logic Unit (ALU) . cái này đã nói rõ tại 1 thời điểm chỉ có 1 thread được chạy, pipeline chỉ giúp tăng tốc độ xử lý khi có nhiều thread hoạt động tại cùng một thời điểmCái này cực kỳ sai nhé. Không có chuyện pipeline có 5 stage thì tại 1 thời điểm có thể chạy được 5 task khác nhau. Tại vì nếu chạy 5 task cùng 1 lúc trên 1 core thì hardware cần phải có đủ resource để giữ được context của 5 task cùng 1 lúc. Nên số lượng task chạy được cùng 1 thời điểm trên 1 core chả liên quan gì đến số stage trong pipeline cả. Chủ thớt hiểu sai về pipeline cmnr,
Hiện tại chỉ có hyper threading thì có thể chạy được 2 thread "đồng thời" trên 1 core thôi.
Tuy nhiên bản chất vẫn là tại một thời điểm thì chỉ có một thread được chạy thôi. Nhưng do hardware đã lưu context hiện tại của 2 thread nên khác với context switch tại OS, context switch tại hardware gần như là zero cost.
Bác đọc thêm slide của bác @Fire Of Heart thì sẽ refine được concept.Cái này cực kỳ sai nhé. Không có chuyện pipeline có 5 stage thì tại 1 thời điểm có thể chạy được 5 task khác nhau. Tại vì nếu chạy 5 task cùng 1 lúc trên 1 core thì hardware cần phải có đủ resource để giữ được context của 5 task cùng 1 lúc. Nên số lượng task chạy được cùng 1 thời điểm trên 1 core chả liên quan gì đến số stage trong pipeline cả. Chủ thớt hiểu sai về pipeline cmnr,
Hiện tại chỉ có hyper threading thì có thể chạy được 2 thread "đồng thời" trên 1 core thôi.
Tuy nhiên bản chất vẫn là tại một thời điểm thì chỉ có một thread được chạy thôi. Nhưng do hardware đã lưu context hiện tại của 2 thread nên khác với context switch tại OS, context switch tại hardware gần như là zero cost.
Bác nhìn slide trang 5-6 , thì thấy tại 1 thời điểm T xác định, có thể có tối đa 5 Instruction. Slide bác Fire Of Heart rất chi tiết, trước mình học ĐH = tiếng Anh , nên ko biết là pipe-line Việt hóa thành ống dẫnĐâ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
Có nhiều stages ko tốn CPU-cycle , nếu hardware support thêm Direct Memory Access (DMA), cho 1 vài instruction copy/swap thì tại stage như WB(writeback) CPU lại assign sang 1 bộ phận khác (MMU - memory management unit , GPU - graphic ...) .
Ý bác là về việc quản lý dependencies/modules của NodeJS ?
Với bài toán này thì bottle-neck chính là ở việc call http -> nếu được thì mình sẽ xử lý batch-processing chứ ko call one-vs-one cho từng row để validate.
Như point 1 của bác thì NodeJS là multi-thread đó
-> thử console.log() trong callback của setInterval() là thấy là chạy thứ tự ko xác định trước.
Như point 1 của bác thì NodeJS là multi-thread đó
JS vẫn phải care về concurrent modification -> bác thử truyền 1 object từ global vào trong callback/promises ( cho 1 hàm random gì đó set value vào biến global). Thì lúc này gía trị của biến global là ko xác định được lúc ở runtime. Thử 1 cái array hoặc JSON từ global vào callback , rồi spam call thử là rõ.
let i = 0;
setInterval(() => {
console.log(i++);
}, 1000);Update lại 1 tẹo thành array , thì sẽ show được cái race-conditionBác có ví dụ không. Em đọc chẳng hiểu gì
Em thử cái này thì thứ tự rất là ổn định
JavaScript:let i = 0; setInterval(() => { console.log(i++); }, 1000);
// Update lại phần này, dùng array element
//let i = 0;
let arr = [0];
setInterval(() => {
arr[0]=arr[0]++;
console.log(arr[0]);
}, 0);
setInterval(() => {
arr[0]=arr[0]+2
console.log(arr[0]);
}, 0);Bác expect cái "mutate đúng" là như thế nào.
Gọi callback của setInterval thứ nhất là f1, callback của setInterval thứ hai là f2. Thứ tự thực hiện sẽ là
f1 vào queue
f2 vào queue
dequeue => f1 chạy => output 0, i = 1, f1 vào queue
dequeue => f2 chạy => output 3, i = 3, f2 vào queue
dequeue => f1 chạy => output 3, i = 4, f1 vào queue
dequeue => f2 chạy => output 6, i = 6, f2 vào queue
dequeue => f1 chạy => output 6, i = 7, f1 vào queue
dequeue => f2 chạy => output 9, i = 9, f2 vào queue
...Bác đọc thêm slide của bác @Fire Of Heart thì sẽ refine được concept.
Bác nhìn slide trang 5-6 , thì thấy tại 1 thời điểm T xác định, có thể có tối đa 5 Instruction. Slide bác Fire Of Heart rất chi tiết, trước mình học ĐH = tiếng Anh , nên ko biết là pipe-line Việt hóa thành ống dẫn
Trước thì ông thầy lấy ví dụ lắp ráp xe của Ford cho phần này.
Có nhiều stages ko tốn CPU-cycle , nếu hardware support thêm Direct Memory Access (DMA), cho 1 vài instruction copy/swap thì tại stage như WB(writeback) CPU lại assign sang 1 bộ phận khác (MMU - memory management unit , GPU - graphic ...) .
Tức là 1 vài instruction, ko block việc fetch các câu instruction khác. Nên vẫn cùng 1 PC vs 1 ALU, nhiều instruction vẫn có thể pipe-line vào cùng 1 lúc. Tất nhiên, càng nhiều stages, kiến trúc hardware càng phức tạp.
Không phải instruction nào cũng tốn CPU-cycle, MIPS chỉ là 1 kiến trúc đơn giản để dạy học.
Tóm lại, mình đưa pipe-line vào trong topic này, vì nó là 1 yếu tố ảnh hưởng đến khả năng concurrency vs multi-threading . Giusp cho việc nắm được idea chính ở đây là : thread trên OS/application nó độc lập với core/thread trên hardware -> việc của dev là muốn chiếm nhiều CPU-cycle hơn thì phải tăng số thread -> tăng số instruction được fetch vào hardware tại 1 lúc nhiều nhất có thể. ( còn việc hardware optimize như thế nào là 1 câu chuyện sâu hơn nhiều)
Đâ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
Vấn đề là 5 instruction này nó không nằm trong 5 thread khác nhau, cùng lắm thì chỉ là 2 nếu cpu là hyper threading. Vì nếu 5 instruction của 5 thread khác nhau cùng được load vào các stage khác nhau trong pipeline thì cần 5 program counter để có thể giữ được vị trí câu lệnh hiện tại của 5 thread. Nên kết luận số stage trong pipeline càng lớn thì càng lằm tăng khả năng concurrency là đang hiểu sai pipeline.
Mình mới update lại thành array-element, để đảm bảo nó access vào memory-address chứ ko phải 1 thread-safe object .
0
2
2
4
4
6
6
8
8
10
10
12
12
14
14
16
16
18
18
20
20
...
