Thuật toán tăng tốc download

[tridung_info]

Bạn nào biết thuật toán sử dụng trong các chương trình hỗ trợ download như IDM, vui lòng chỉ mình với

[vtnphong]

xài multi-threading :D Cái này thì pascal chịu chết

[tridung_info]

bạn nói cụ thể hơn đi

[zumzumsg]

chỉ can mở sách giải!
Đơn giản wé he

[vtnphong]

bạn nói cụ thể hơn đi

Xử lý đa tuyến. Cái này không phải thuật giải mà nó nằm trong thư viện của các ngôn ngữ hiện đại như Java hay C++. Nói chung là nó sẽ cho phép xử lý song song nhiều tác vụ cùng một lúc (ở đây là nó sẽ chia file cần download ra nhiều đoạn rồi mỗi thread sẽ xử lý một đoạn). Với một số lượng thread thích hợp thì tốc độ sẽ tăng lên rất nhiều so với download từ đầu tới cuối theo phương pháp thông thường.

[Vrohto]

Xử lý đa tuyến. Cái này không phải thuật giải mà nó nằm trong thư viện của các ngôn ngữ hiện đại như Java hay C++. Nói chung là nó sẽ cho phép xử lý song song nhiều tác vụ cùng một lúc (ở đây là nó sẽ chia file cần download ra nhiều đoạn rồi mỗi thread sẽ xử lý một đoạn). Với một số lượng thread thích hợp thì tốc độ sẽ tăng lên rất nhiều so với download từ đầu tới cuối theo phương pháp thông thường.

Trả lời trật lấc rồi bồ :D. Chắc bồ nhìn thấy giao diện đồ họa của Flashget nên phán thế phải không :)). Đúng là phải đa luồng nhưng cái phần tinh túy nhất của nó bồ kô có đề cập đến ;)

[vtnphong]

flashget? :S Chưa bao giờ xài tới. Mình trung thành với cái download của IE :)

ủa, dùng multi-threading để download song song từng fragments của file là kỹ thuật chung của mấy cái download accelerator mà. Còn đương nhiên là mỗi software sẽ có một số bổ sung để tốc độ download nhanh hơn cho nên chẳng có thằng nào cho tốc độ giống thằng nào hết. Ngồi tìm ra mấy cái kỹ thuật đó của mỗi thằng thì mệt lắm :-|

Bạn đã biết rồi thì post lên đi, mình cũng muốn biết :D

[nhc1987]

Tui cũng chỉ biết mỗi cái multi thread lol

Bạn nào có cái nào hay hơn thì học hỏi với lol

[vtnphong]

ủa, bạn Vrohto đâu rồi? Cái thread này mở được 3 ngày rồi đó mà ko ai trả lời cả.

[VuongChieuQuan]

Hỏi gì khó dữ vậy, bạn hỏi luôn thuật toán search của google luôn thể đi...Hic hic

Các trình trên Win cái nào chả đa tuyến, đa luồng ! Nhưng đa luồng thì liên quan gì đến thuật toán đâu. Bạn ấy hỏi thuật toán kia !

[thuongshoo]

hình như orbit cũng mã nguồn mở thì phải?
Cái này dĩ nhiên là mình phải multi thread rồi! nhưng mà mình gởi nhiều connecttion tới server thì thằng server nó chịu hôn?

[meotrang7x]

ủa, bạn Vrohto đâu rồi? Cái thread này mở được 3 ngày rồi đó mà ko ai trả lời cả.

Chắc có thể thêm 1 server trung gian download về, rồi nén lại (theo thuật toán nén của chương trình download) rồi mới send về client quá.

Download site <--high speed--> Middle server <--slow speed-->client

My 2 cents

Còn cách nào nữa không ta?

[temp2]

Chắc có thể thêm 1 server trung gian download về, rồi nén lại (theo thuật toán nén của chương trình download) rồi mới send về client quá.

Download site <--high speed--> Middle server <--slow speed-->client

My 2 cents

Còn cách nào nữa không ta?

làm sao dùng server trung gian đc? Server nào mà khủng đến vậy? Ý tưởng chỉ có thể là nhiều connection đến file, còn vấn đề xử lí của các soft ra sao thì pó tay

[meotrang7x]

làm sao dùng server trung gian đc? Server nào mà khủng đến vậy? Ý tưởng chỉ có thể là nhiều connection đến file, còn vấn đề xử lí của các soft ra sao thì pó tay

Uhm, mình ban đầu cũng nghĩ vậy (chẳng phải là cái multi threading mà có bạn đã đề cập ở trên rồi ư?) nhưng có người nói còn cách khác nữa nên nghĩ ra thêm cho vui mà. :D

[vtnphong]

Các trình trên Win cái nào chả đa tuyến, đa luồng ! Nhưng đa luồng thì liên quan gì đến thuật toán đâu. Bạn ấy hỏi thuật toán kia !

Hình như ko phải cái nào trên Win cũng là multi-threading đâu. Mặc Windows luôn có cơ chế để phân chia thời gian xử lý nhiều chương trình chạy song song với nhau nhưng mà ở đây đang nói về việc lập trình để 1 chương trình tự schedule các tasks của mình kìa (cách xử lý thế nào cho mỗi thread đúng là cả một thuật toán đó, chứ ko phải chỉ đơn giản là gọi method có sẵn đâu)

[s.code]

Tôi nghĩ multi-threading là điều đương nhiên. Tuy nhiên theo tôi multi-threading không phải là mấu chốt của thuật toán này. Sử lý đa luồng => hiển nhiên, Đa kết nối => hiển nhiên. Tuy vậy bí kíp là làm sao nói chuyện cho server hiểu là muốn down từ đoạn nào của file mà thôi.

Ví dụ:

Đang down 1 file 10MB.

Mở kết nối đầu tiên xin tải từ byte đầu tiên đến byte 1000
Mở kết nối thứ 2 xin tải từ byte 1001 đến byte 20000
....................

Tất nhiên phải dc sự chấp nhận của server để có thể cùng 1 thời điểm có nhiều kết nối từ 1 client. Có một số server config chỉ cho client 1 kết nối trong cùng 1 thời điểm. Lúc này IDM cũng bó tay. Bác nào down nhiều chắc gặp chuyện này là bình thường. Thử down tư rapidshare ko dùng acc mà dùng free thì biết.

Hơ ko biết các bác nghĩ sao. Nhưng theo em thế là đúng đó.

[vtnphong]

Nếu vậy thì topic của cái thread này phải là hỏi về protocol chứ ko phải là về algorithm.

[scooby]

multi-threads có nghĩa là xử lý song song. Tuy nhiên thêm thread khi download chẳng có ý nghĩa gì nhiều. Giống như vào quán ăn một người gọi món (cho 3 người) hay cả 3 người cùng gọi món thì cũng phải chờ như nhau thôi.

Cái ảnh hưởng chính đến tốc độ download là tốc độ của đường truyền. Một số đường có tốc độ cao hơn đường khác. Đường có 3 làn xe chạy song song thì đương nhiên là nhanh hơn đường chỉ có 1 làn. Tuy nhiên nếu trên toàn tuyến đường có một chỗ nghẽn thành 1 làn thì cả tuyến đường chỉ có giá trị tương đương với đường 1 làn thôi.

Do vậy muốn cải thiện việc download người ta dùng kết hợp các biện pháp:
- Nén dữ liệu cho nhỏ đi. Tuy nhiên với các file ảnh, nhạc MP3 hoặc file đã nén rồi thì cách này bó tay (vì không nén thêm được nữa).
- Chia dữ liệu thành các gói nhỏ. Thực ra bản chất Internet là IP/TCP đã tự động chia dữ liệu thành các gói nhỏ để truyền đi rồi. Chia thêm chỉ tổ rách việc. Tuy nhiên nếu nghiên cứu kỹ thì có thể có cách chia nào đó tối ưu hơn là để chia tự động. Mặt khác việc chia chủ động có thể giúp cho các phần sau hoạt động tốt hơn.
- Cả server lẫn trình download đều biết tiếp tục download gữa chừng. Sự cố mạng rất hay xẩy ra. Đang download mà bị đứt thì phải làm lại, vừa mất thời gian mà nếu lại tiếp tục đứt thì chẳng biết bao giờ xong. Nếu download được tiếp từ chỗ đứt thì tốt hơn nhiều. Tôi đánh giá đây là phương pháp trợ giúp hiệu quả nhất.
- Truyền các gói dữ liệu theo nhiều đường khác nhau. Ví dụ nếu ta download 1 file nhạc ở Mỹ, thì sau khi chia nhỏ ra, gói 1 có thể truyền theo đường cáp biển qua Đài Loan rồi đến VN. Cùng lúc đó, gói 2 được truyền qua đường vệ tinh đến VN và gói 3 lại được truyền qua châu Âu, Trung Á rồi đến VN. Nếu mọi thứ hoạt động trơn chu thì ta sẽ nhận được 3 gói và tổng thời gian sẽ ít hơn so với nhận lần lượt gói 1, rồi gói 2, gói 3 cùng chuyển về bằng một đường.

Cái này là đảm bảo thay cho đường 3 làn là dùng luôn 3 đường khác nhau. Tất nhiên muốn làm được vậy thì server phải biết cách gửi thông tin qua nhiều ngả khác nhau. Cả chương trình gửi và nhận phải đủ thông minh để biết gói nào thất lạc mà gửi lại, đường nào đang thông thành đường tắc để tránh gửi tiếp. Một số server thông minh đến mức sẽ biết khi nào nên tách dữ liệu ra gửi đi theo nhiều đường, khi nào không và khi có nhiều đường truyền chúng còn biết chọn những đường nhanh nhất để gửi và bỏ qua các đường chậm.

Việc download bằng cách này sẽ chẳng hơn gì cách thường nếu server chỉ thấy có mỗi 1 đường gửi thông tin hoặc một vài đường đang dùng để gửi lại bị lag/lỗi nhiều hoặc đến nhưng đoạn hợp nhất lại thì bị chậm, ví dụ khi ba gói đến server của Vietel thì đoạn từ Vietel đến nhà bạn mới là đoạn bị lag thì công dã tràng cả.

Nói chung các chương trình hỗ trợ download không giúp được trong mọi trường hợp, nhưng cũng có lúc giúp được ít nhiều.

[vtnphong]

multi-threads có nghĩa là xử lý song song. Tuy nhiên thêm thread khi download chẳng có ý nghĩa gì nhiều. Giống như vào quán ăn một người gọi món (cho 3 người) hay cả 3 người cùng gọi món thì cũng phải chờ như nhau thôi.


Mình không đồng ý với cái này. Bạn đã bao giờ xài mấy chương trình scanip hay password recovery chưa? Bạn sẽ thấy là có sự khác biệt lớn về tốc độ giữa việc sử dụng multithreading với việc chạy bình thường.

[s.code]

multi-threads có nghĩa là xử lý song song. Tuy nhiên thêm thread khi download chẳng có ý nghĩa gì nhiều. Giống như vào quán ăn một người gọi món (cho 3 người) hay cả 3 người cùng gọi món thì cũng phải chờ như nhau thôi.

Cái ảnh hưởng chính đến tốc độ download là tốc độ của đường truyền. Một số đường có tốc độ cao hơn đường khác. Đường có 3 làn xe chạy song song thì đương nhiên là nhanh hơn đường chỉ có 1 làn. Tuy nhiên nếu trên toàn tuyến đường có một chỗ nghẽn thành 1 làn thì cả tuyến đường chỉ có giá trị tương đương với đường 1 làn thôi.

Do vậy muốn cải thiện việc download người ta dùng kết hợp các biện pháp:
- Nén dữ liệu cho nhỏ đi. Tuy nhiên với các file ảnh, nhạc MP3 hoặc file đã nén rồi thì cách này bó tay (vì không nén thêm được nữa).
- Chia dữ liệu thành các gói nhỏ. Thực ra bản chất Internet là IP/TCP đã tự động chia dữ liệu thành các gói nhỏ để truyền đi rồi. Chia thêm chỉ tổ rách việc. Tuy nhiên nếu nghiên cứu kỹ thì có thể có cách chia nào đó tối ưu hơn là để chia tự động. Mặt khác việc chia chủ động có thể giúp cho các phần sau hoạt động tốt hơn.
- Cả server lẫn trình download đều biết tiếp tục download gữa chừng. Sự cố mạng rất hay xẩy ra. Đang download mà bị đứt thì phải làm lại, vừa mất thời gian mà nếu lại tiếp tục đứt thì chẳng biết bao giờ xong. Nếu download được tiếp từ chỗ đứt thì tốt hơn nhiều. Tôi đánh giá đây là phương pháp trợ giúp hiệu quả nhất.
- Truyền các gói dữ liệu theo nhiều đường khác nhau. Ví dụ nếu ta download 1 file nhạc ở Mỹ, thì sau khi chia nhỏ ra, gói 1 có thể truyền theo đường cáp biển qua Đài Loan rồi đến VN. Cùng lúc đó, gói 2 được truyền qua đường vệ tinh đến VN và gói 3 lại được truyền qua châu Âu, Trung Á rồi đến VN. Nếu mọi thứ hoạt động trơn chu thì ta sẽ nhận được 3 gói và tổng thời gian sẽ ít hơn so với nhận lần lượt gói 1, rồi gói 2, gói 3 cùng chuyển về bằng một đường.

Cái này là đảm bảo thay cho đường 3 làn là dùng luôn 3 đường khác nhau. Tất nhiên muốn làm được vậy thì server phải biết cách gửi thông tin qua nhiều ngả khác nhau. Cả chương trình gửi và nhận phải đủ thông minh để biết gói nào thất lạc mà gửi lại, đường nào đang thông thành đường tắc để tránh gửi tiếp. Một số server thông minh đến mức sẽ biết khi nào nên tách dữ liệu ra gửi đi theo nhiều đường, khi nào không và khi có nhiều đường truyền chúng còn biết chọn những đường nhanh nhất để gửi và bỏ qua các đường chậm.

Việc download bằng cách này sẽ chẳng hơn gì cách thường nếu server chỉ thấy có mỗi 1 đường gửi thông tin hoặc một vài đường đang dùng để gửi lại bị lag/lỗi nhiều hoặc đến nhưng đoạn hợp nhất lại thì bị chậm, ví dụ khi ba gói đến server của Vietel thì đoạn từ Vietel đến nhà bạn mới là đoạn bị lag thì công dã tràng cả.

Nói chung các chương trình hỗ trợ download không giúp được trong mọi trường hợp, nhưng cũng có lúc giúp được ít nhiều.

Tôi mới đọc dc mấy dòng đã thấy bác này suy luận kiểu ma tây gì. Tôi đồng ý là tốc độ download phụ thuộc yếu tố đầu tiên là đường truyền. Tuy vậy trong trường hợp vẫn đường truyền như vậy thì các yếu tố còn lại mới quyết định.

Một phép so sánh đơn giản là: tại sao phải sinh ra các trương trình down load ví dụ như IDM hoặc flashget.

Nếu như bác nói thì dùng luôn trình download của trình duyệt luôn đi.

Bó tay.

[scooby]

Mình không đồng ý với cái này. Bạn đã bao giờ xài mấy chương trình scanip hay password recovery chưa? Bạn sẽ thấy là có sự khác biệt lớn về tốc độ giữa việc sử dụng multithreading với việc chạy bình thường.

Tôi đang nói về chuyện download cơ mà. Multi threads có ích với một số việc nhưng ít hiệu quả hơn với một số việc khác. Không phải thấy tay hàng xóm dùng thuốc bắc trở thành khỏe mà ta cũng chơi thuốc bắc như hắn được. Không có thuốc vạn năng cho mọi loại bệnh.

Nếu bạn muốn tranh luận ngoài lề, tôi có thể nói thêm:
- Hầu như chương trình Win nào mà chả multi threads. Ít ra một cái thread cho giao diện, còn một cái xử lý gì đó bên trong.
- password recovery (tôi không biết scanip) nặng về tính toán. Thêm thread để tính toán cho nó không giải quyết được gì đâu (vì 1 thread đã chơi gần như 100% CPU rồi). Phải thêm CPU hoặc lõi nữa thì thread thêm mới giúp nhanh được.




Tôi mới đọc dc mấy dòng đã thấy bác này suy luận kiểu ma tây gì. Tôi đồng ý là tốc độ download phụ thuộc yếu tố đầu tiên là đường truyền. Tuy vậy trong trường hợp vẫn đường truyền như vậy thì các yếu tố còn lại mới quyết định.

Một phép so sánh đơn giản là: tại sao phải sinh ra các trương trình down load ví dụ như IDM hoặc flashget.


Ý của bạn là gì? Tôi nói rõ là không phải luôn luôn nhưng cũng có lúc các chương trình đó giúp ích cơ mà?

Các chương trình thương mại không phải là thước đo chuản. Đã có nhiều chương trình thương mại từng bố láo về kết quả đấy. Ví dụ ngày xưa có chương trình quảng cáo giúp tăng gấp đôi RAM nhưng thực ra chỉ là mẹo lừa thôi. Ngay cả các chương trình phổ biến ngày nay như chống phân mảnh đĩa người ta cũng còn đang cãi nhau chán về tính hiệu quả của chúng (có thực sự có ích không?).




Nếu như bác nói thì dùng luôn trình download của trình duyệt luôn đi.

Bó tay.

Thì cũng phải đến 99% người dùng không dùng các chương trình hỗ trợ download đó thôi. Nếu thật sự các "mẹo" tôi đã nêu trên giúp được nhiều thì cả MS lẫn Mozila đã tích hợp luôn vào trình duyệt của họ cho rồi.

Mà tại sao hai bạn này lại xửng cồ vậy nhỉ? Tôi nói cách người ta đã làm chứ có phải cách do tôi nghĩ ra đâu mà đồng ý với chả không.

[vtnphong]

Tôi đang nói về chuyện download cơ mà. Multi threads có ích với một số việc nhưng ít hiệu quả hơn với một số việc khác. Không phải thấy tay hàng xóm dùng thuốc bắc trở thành khỏe mà ta cũng chơi thuốc bắc như hắn được. Không có thuốc vạn năng cho mọi loại bệnh.

Nếu bạn muốn tranh luận ngoài lề, tôi có thể nói thêm:
- Hầu như chương trình Win nào mà chả multi threads. Ít ra một cái thread cho giao diện, còn một cái xử lý gì đó bên trong.
- password recovery (tôi không biết scanip) nặng về tính toán. Thêm thread để tính toán cho nó không giải quyết được gì đâu (vì 1 thread đã chơi gần như 100% CPU rồi). Phải thêm CPU hoặc lõi nữa thì thread thêm mới giúp nhanh được.


Vấn đề là hình như bạn có nói chuyện 3 người cùng đặt hàng một lúc trong nhà hàng thì thời gian cũng bằng như từng người đặt hàng. Như vậy có nghĩa là theo bạn thì việc multithreading không có tác dụng nếu như chỉ có 1 thằng xử lý request từ nhiều thằng.

Do đó mình mới đưa ví dụ về cái password recovery chứ (một đống thread cùng request cái CPU của computer cùng một lúc mà). Về bản chất thì giữa cái này với download managers cũng tương đối giống nhau. Mà mình xài pass recovery cũng từ lâu rồi, trước khi có dual core kìa nên không thể lý giải là do đa nhân nó nhanh hơn được trong trường hợp này (đồng ý là đa nhân sẽ nhanh hơn, không bàn cãi).

Còn về việc bạn bảo chương trình Win nào cũng xài multithreading thì mình không đồng ý. Rõ ràng là các tasks của các Win apps đều được OS phân phối thời gian chứ ko còn mỗi lệnh một lần như khi còn xài DOS nữa. Tuy nhiên, trong các sách mình đọc và đã học thì khi nói về multithreading trong lập trình là nói về việc tự tạo thread rồi phân phối thời gian cho nó (ví dụ là thừa kế lớp Thread trong Java chẳng hạn, dùng mấy hàm như sleep, notify,.. để kiểm soát các thread này).

Mình thấy rõ ràng là pass recovery chạy nhanh hơn với thread (hiển nhiên là cùng thuật toán và cùng máy rồi chứ chẳng lẽ khi không mình chuyển máy sao :))



Các chương trình thương mại không phải là thước đo chuản. Đã có nhiều chương trình thương mại từng bố láo về kết quả đấy. Ví dụ ngày xưa có chương trình quảng cáo giúp tăng gấp đôi RAM nhưng thực ra chỉ là mẹo lừa thôi. Ngay cả các chương trình phổ biến ngày nay như chống phân mảnh đĩa người ta cũng còn đang cãi nhau chán về tính hiệu quả của chúng (có thực sự có ích không?).

Thì cũng phải đến 99% người dùng không dùng các chương trình hỗ trợ download đó thôi. Nếu thật sự các "mẹo" tôi đã nêu trên giúp được nhiều thì cả MS lẫn Mozila đã tích hợp luôn vào trình duyệt của họ cho rồi.

Mà tại sao hai bạn này lại xửng cồ vậy nhỉ? Tôi nói cách người ta đã làm chứ có phải cách do tôi nghĩ ra đâu mà đồng ý với chả không.

Các chương trình thương mại ko phải là thước đo chuẩn thì theo bạn chương trình nào là thước đo chuẩn, open source sao? :D

Một lần nữa, con số 99% mà bạn đưa ra lấy từ nguồn nào vậy? Làm ơn đừng tự chế số rồi đưa vào như vậy chứ. Firefox có plugin hỗ trợ download là downthemall (Mozilla bảo là tăng tốc 400%, nhưng cũng chẳng quan trọng nhỉ vì nó chắc cũng chỉ xạo thôi :)). IE thì sẽ không bao giờ dám đưa vào vì chỉ nội vụ tích hợp IE với hệ điều hành là nó đã bị kiện độc quyền tùm lum rồi, thêm cái này vào để giành miếng ăn của anh em thì ai để cho sống chứ.

Chill man, :D Chẳng ai sửng cồ đâu. Chỉ tranh luận cho vui thôi mà

[s.code]

Ý của bạn là gì? Tôi nói rõ là không phải luôn luôn nhưng cũng có lúc các chương trình đó giúp ích cơ mà?

Các chương trình thương mại không phải là thước đo chuản. Đã có nhiều chương trình thương mại từng bố láo về kết quả đấy. Ví dụ ngày xưa có chương trình quảng cáo giúp tăng gấp đôi RAM nhưng thực ra chỉ là mẹo lừa thôi. Ngay cả các chương trình phổ biến ngày nay như chống phân mảnh đĩa người ta cũng còn đang cãi nhau chán về tính hiệu quả của chúng (có thực sự có ích không?).


Không cần thước đo chuẩn. Chỉ cần biết một điều: Cộng đồng đã yêu thích sử dụng các sản phẩm nào thì ắt hẳn nó phải hơn. <= không liên quan gì đến tin học.

mà điều này thực tế chứng minh. bạn hãy bật IDM lên download 1 file và mở trình duyệt lên down load chính file đó. Từ đó bạn sẽ rút ra thằng nào hơn. Tính hiệu quả thật hay ảo. Nhớ test vài link để thống kê cho tốt.



Thì cũng phải đến 99% người dùng không dùng các chương trình hỗ trợ download đó thôi. Nếu thật sự các "mẹo" tôi đã nêu trên giúp được nhiều thì cả MS lẫn Mozila đã tích hợp luôn vào trình duyệt của họ cho rồi.


nên đính chính lại chỗ này. bác thử đi hỏi tất cả những ai hay download và download những file nặng xem họ có nói ko dùng trình download nào ko (chỉ dùng của trình duyêt)

[scooby]

Ok, tranh luận cho vui thì được, đằng nào hôm nay cũng là ngày cuối tuân rồi.


Vấn đề là hình như bạn có nói chuyện 3 người cùng đặt hàng một lúc trong nhà hàng thì thời gian cũng bằng như từng người đặt hàng. Như vậy có nghĩa là theo bạn thì việc multithreading không có tác dụng nếu như chỉ có 1 thằng xử lý request từ nhiều thằng.

Do đó mình mới đưa ví dụ về cái password recovery chứ (một đống thread cùng request cái CPU của computer cùng một lúc mà). Về bản chất thì giữa cái này với download managers cũng tương đối giống nhau. Mà mình xài pass recovery cũng từ lâu rồi, trước khi có dual core kìa nên không thể lý giải là do đa nhân nó nhanh hơn được trong trường hợp này (đồng ý là đa nhân sẽ nhanh hơn, không bàn cãi).

Còn về việc bạn bảo chương trình Win nào cũng xài multithreading thì mình không đồng ý. Rõ ràng là các tasks của các Win apps đều được OS phân phối thời gian chứ ko còn mỗi lệnh một lần như khi còn xài DOS nữa. Tuy nhiên, trong các sách mình đọc và đã học thì khi nói về multithreading trong lập trình là nói về việc tự tạo thread rồi phân phối thời gian cho nó (ví dụ là thừa kế lớp Thread trong Java chẳng hạn, dùng mấy hàm như sleep, notify,.. để kiểm soát các thread này).



Cả hai bạn này cần đọc và hiểu kỹ bài của tôi. Tôi không nói "mọi chương trình" mà đa số chương trình. Hiển nhiên các chương trình dạng amateur thì ít khi dùng trên 1 thread lắm. Còn bất cứ chương trình nào mà khi nó đang làm việc mà bạn vẫn có thể vào giao diện của chúng thì phải có ít nhất là 2 threads.





Mình thấy rõ ràng là pass recovery chạy nhanh hơn với thread (hiển nhiên là cùng thuật toán và cùng máy rồi chứ chẳng lẽ khi không mình chuyển máy sao :))


Thực ra tôi cũng chi biết qua về chương trình này mà chưa bao giờ dùng. Tuy nhiên tôi có thể chắc chắn rằng nếu máy của bạn chỉ có 1 CPU/lõi thì đừng nghĩ đến chuyện tăng số thread cho phần tính toán. Việc này cũng giống như chuyện bạn có một máy phát điện 100W, dùng 2 dây nối vào thì bạn có thể thắp cùng lúc hai bóng đèn 100 W đấy. Năng lượng (hay công suất tính toán) không từ trên trời xuống đâu.

Mà theo tôi hiểu đa số chương trình sẽ tự quyết định số thread chứ không thèm hỏi ý kiến người dùng đâu.




Các chương trình thương mại ko phải là thước đo chuẩn thì theo bạn chương trình nào là thước đo chuẩn, open source sao? :D



Bạn "máu quá" phản bác hộ cả người khác ;)

Chẳng anh nào là chuẩn cả. Được chưa? Do vậy nói chương trình thương mại này, open source kia làm được cái gì đó thì nên chờ kiểm chứng từ chính bản thân lẫn nhiều người khác. Không nên tin chúng như kinh thánh.




Một lần nữa, con số 99% mà bạn đưa ra lấy từ nguồn nào vậy? Làm ơn đừng tự chế số rồi đưa vào như vậy chứ.


OK, con số do tôi nhào nặn đấy. Cũng có sao đâu. Chẳng là tôi lẫn hầu hết những người tôi biết cũng đã từng thử cài mấy cái chương trình đó rồi cũng lần lượt gỡ hết. Chúng cũng có ích đấy, nhưng nhìn chung rách việc và phiền toái thêm nhiều.

Vậy thì chuyển thành 99% số người tôi biết nhé ;)



Firefox có plugin hỗ trợ download là downthemall (Mozilla bảo là tăng tốc 400%, nhưng cũng chẳng quan trọng nhỉ vì nó chắc cũng chỉ xạo thôi :)). IE thì sẽ không bao giờ dám đưa vào vì chỉ nội vụ tích hợp IE với hệ điều hành là nó đã bị kiện độc quyền tùm lum rồi, thêm cái này vào để giành miếng ăn của anh em thì ai để cho sống chứ.


Như tôi nói, mấy cái "mẹo" này có tác dụng, nhưng không luôn luôn. Trước hết cái plugin đó chỉ tác dụng khi server cũng phải cài chương trình hỗ trợ của Mozilla. Các đường truyền phải cùng lúc trơn chu. Và một khi mạng VN mà bị lag quá thì làm gì có chuyện hơn nổi 1%.

MS đâu có sợ ai mà bảo nó chùn tay? Nếu nó thấy đúng là tăng tốc được dủ chỉ thêm 50% thì Flashget tự giải tán đi (hoặc xin bán thân cho MS) cho rồi.




Chill man, :D Chẳng ai sửng cồ đâu. Chỉ tranh luận cho vui thôi mà


Thực ra tôi viết bài trên là muốn giúp mọi người hiểu biết thêm về các chương trình trợ giúp download, cái được và cái không được (chứ không hề nói chúng vô dụng hoàn toàn). Tôi đã từng tìm hiểu về chúng và viết ra với dụng ý giúp mọi người hiểu được các phương pháp cơ bản "người ta đã và đang làm" chứ không phải là đoán mò về cách làm như vài bạn đang cố phỏng đoán, từ đó nếu ai có ảo tưởng quả về chúng sẽ hiểu hơn và ai thích có thể đi tiếp dễ dàng hơn.

[jiSh@n]

DownThemAll (dTA) có khả năng tăng tốc download đối với mọi file nằm trên mọi server có hỗ trợ multiconnection-per-file so với trình download chuẩn của Mozilla.
Tất cả các ứng dụng download manager có khả năng tăng tốc download so với tính năng download chuẩn của trình duyệt.
Khả năng tăng tốc download phụ thuộc lớn nhất vào đường truyền rồi mới đến multi-threading. Tất cả các graphical web browser đều là multi-thread, nghĩa là có thể tạo ra nhiều thread, mỗi thread tạo 1 connection gửi request đến 1 file. Nếu đường truyền mạnh thì tốc độ download vẫn rất cao (IE vẫn có thể đạt tốc độ 2MB/s khi download 1 file bằng đường truyền rất mạnh). Tuy nhiên, nếu gặp đường truyền tốc độ thấp thì khả năng download khá kém, và nếu timeout thì coi như phải download từ đầu vì ko có khả năng resume. Một download manager tương tự là wget, chỉ tạo 1 connection đến 1 file, nhưng tốc độ vẫn rất cao nếu dùng dường truyền mạnh (tôi đã từng dùng wget thông qua ssh để down file về server với tốc độ 2,5MB/s bằng giao thức FTP).

Các trình tăng tốc download làm việc hơi khác 1 chút. Thông thường, chúng mở nhiều thread (connection) cho cùng 1 file. Kỹ thuật này ko có gì là mới mẻ hay cao siêu vì đây là 1 đặc tả kỹ thuật của giao thức HTTP: HTTP-Range. Gửi thông số Range đi kèm HTTP request để báo cho server biết cần lấy từ đoạn nào của file. Đương nhiên, kỹ thuật này cần phải được server hỗ trợ. Các server ko hỗ trợ resume đều ko hỗ trợ HTTP-Range. Đối với các server giới hạn 1 connection thì các DM ko thể mở nhiều connection (connection 1 thành công, các connection còn lại đều bị canceled), tuy nhiên vẫn có thể resume nếu server chấp nhận HTTP-Range.

Với 1 đường truyền ko ổn định thì dùng các DM hỗ trợ nhiều connection sẽ tăng tốc rất đáng kể khi download cùng 1 file, lý do 1 connection có thể ko chiếm hết đường truyền, hoặc băng thông 1 connection bị giới hạn khi đến server, gộp nhiều connection lại có thể tận dụng tối đa băng thông. Vào các tiệm internet nhỏ thử nghiệm để thấy tốc độ kinh khủng của Flashget/IDM : 1 máy bật Flashget/IDM lên download file to là dàn game online còn lại sẽ nếm mùi lag và dis lol Tuy nhiên, nếu bật trình download mặc định của browser thì chẳng hề hấn gì.

[VuongChieuQuan]

Như vậy theo các bác thì mấy trình hỗ trợ download chả cần thuật toán gì đúng không.

[jiSh@n]

Như vậy theo các bác thì mấy trình hỗ trợ download chả cần thuật toán gì đúng không.

Ko phải ko cần, mà là ko có gì cao siêu hay đặc biệt.

[lee_huynh306]

multi-threads có nghĩa là xử lý song song. Tuy nhiên thêm thread khi download chẳng có ý nghĩa gì nhiều. Giống như vào quán ăn một người gọi món (cho 3 người) hay cả 3 người cùng gọi món thì cũng phải chờ như nhau thôi.

- Multi-threads không có nghĩa là xử lý song song. Khái niệm xử lý song song trong lập trình là parallel.
- Bạn không thể mang tất tần tật chuyện đời thường đi so với một cái máy được. Trong một việc đơn giản là truyền 1 gói tin nhỏ đi cùng lúc cho nhiều người thì một cái PC làm tốt hơn con người phục vụ món ăn cho 3 người bạn ạ.
- Sự thật hiển nhiên, chia nhiều thread dể download lúc nào nó cũng nhanh hơn cả. Nói một cách đơn giản, server truyền 1 gói tin đến client cần một khoảng thời gian nhất định, client report trở lại server đã nhận tin và lấy tin mới cũng cần một khoảng thời gian nữa, vì phải đi qua rất nhiều đường mới tới đích. Trong 2 khoảng thời gian đó, rõ ràng client, server và cả đường truyền đều rảnh rỗi. Để tận dụng khoảng thời gian rỗi này, các trình download đã tạo nên nhiều luồng để download 1 file về nếu server hỗ trợ.

[scooby]

Bạn nói không có gì sai. Nhưng về bản chất tôi nói A thì bạn cũng đang nói A đấy. Có lẽ bạn chưa hiểu kỹ bài tôi viết mà đã quá chú ý bắt bẻ câu chữ.

Ngoài ra tôi có thể chắc nhiều bạn đang giảng giải ở đây như chuyên gia nhưng lại chưa từng viết chương trình multi threads cũng như chương trình download ;)

[s.code]

@scooby: Siêu bảo thủ. Cả topic này mỗi bác này có cách suy luận 1 hướng.

Tất nhiên "Chân lý không hẳn thuộc về số đông". Nhưng 99,99% chân lý luôn thuộc về số đông :D.



Nói một cách đơn giản, server truyền 1 gói tin đến client cần một khoảng thời gian nhất định, client report trở lại server đã nhận tin và lấy tin mới cũng cần một khoảng thời gian nữa, vì phải đi qua rất nhiều đường mới tới đích. Trong 2 khoảng thời gian đó, rõ ràng client, server và cả đường truyền đều rảnh rỗi. Để tận dụng khoảng thời gian rỗi này, các trình download đã tạo nên nhiều luồng để download 1 file về nếu server hỗ trợ.


Tôi đồng ý với ý kiến này

[darkera13]

scooby có phải là lấy theo tên bộ phim hoạt hình "Scooby Doo" không nhỉ? Chắc bác này hâm mộ chú chó scooby doo trong đó lắm nhỉ. Phim này xem hài phết.

[xuanhau]

firefox quảng cáo là download nhanh hơn IE nhiều multi-threads. vậy sao không có ai đó mổ bụng thằng FF ra để xem nó nhỉ lol

[jiSh@n]

Bạn nói không có gì sai. Nhưng về bản chất tôi nói A thì bạn cũng đang nói A đấy. Có lẽ bạn chưa hiểu kỹ bài tôi viết mà đã quá chú ý bắt bẻ câu chữ.

Ngoài ra tôi có thể chắc nhiều bạn đang giảng giải ở đây như chuyên gia nhưng lại chưa từng viết chương trình multi threads cũng như chương trình download ;)

Lỡ mang tiếng "bắt bẻ" nên cũng phải làm sao cho xứng lol

multi-threads có nghĩa là xử lý song song.
Cái này lee_huynh306 cũng đã nói. Ai đã từng học về lập trình đến nơi đến chốn đều biết xử lý song song (parallel processing) và lập trình đa tuyến (multi-threading) là 2 khái niệm hoàn toàn khác nhau. Multi-thread làm cho người dùng thấy có nhiều tác vụ đang chạy đồng thời, nhưng thực tế tại mỗi thời điểm chỉ có 1 tác vụ đang hoạt động (trên 1 CPU). Trong khi đó xử lý song song lại phức tạp hơn rất nhiều, đòi hỏi phải có các thuật toán xử lý song song và ko phải muốn là làm được như multi-thread.


- Truyền các gói dữ liệu theo nhiều đường khác nhau. Ví dụ nếu ta download 1 file nhạc ở Mỹ, thì sau khi chia nhỏ ra, gói 1 có thể truyền theo đường cáp biển qua Đài Loan rồi đến VN. Cùng lúc đó, gói 2 được truyền qua đường vệ tinh đến VN và gói 3 lại được truyền qua châu Âu, Trung Á rồi đến VN. Nếu mọi thứ hoạt động trơn chu thì ta sẽ nhận được 3 gói và tổng thời gian sẽ ít hơn so với nhận lần lượt gói 1, rồi gói 2, gói 3 cùng chuyển về bằng một đường.
Tôi ko biết bạn sẽ truyền dữ liệu theo nhiều đường khác nhau như thế nào? Client và server chỉ biết gửi/nhận packet từ gateway hoặc router gần nó nhất, còn đoạn đường ở giữa thì can thiệp bằng cách nào khi nó được điều khiển bởi các router trung gian?

Cả chương trình gửi và nhận phải đủ thông minh để biết gói nào thất lạc mà gửi lại, đường nào đang thông thành đường tắc để tránh gửi tiếp. Một số server thông minh đến mức sẽ biết khi nào nên tách dữ liệu ra gửi đi theo nhiều đường, khi nào không và khi có nhiều đường truyền chúng còn biết chọn những đường nhanh nhất để gửi và bỏ qua các đường chậm.
Chuyện các packet thất lạc ko đến nơi sẽ được phản hồi và gửi lại lại là đặc tả của giao thức TCP/IP. Lựa chọn đường để gửi packet là nhiệm vụ của các router. Server và client ko đóng vài trò gì ở các thao tác này, và cũng ko cần phải có sự "thông minh" để làm những điều đó.

Việc download bằng cách này sẽ chẳng hơn gì cách thường nếu server chỉ thấy có mỗi 1 đường gửi thông tin hoặc một vài đường đang dùng để gửi lại bị lag/lỗi nhiều hoặc đến nhưng đoạn hợp nhất lại thì bị chậm, ví dụ khi ba gói đến server của Vietel thì đoạn từ Vietel đến nhà bạn mới là đoạn bị lag thì công dã tràng cả.
Các server loại thường thì cũng chỉ có mỗi 1 đường kết nối ra internet, client thông thường thì cũng chỉ có 1 thôi (ko đề cập đến các hệ thống load balance). Và packet gửi đi bị rớt giữa đường thì đã có giao thức TCP/IP lo việc thông báo và gửi lại.

Khoảng cách giữa server và client quá gần thì dùng hay ko dùng các trình download cũng ko có khác biệt mấy. Nhưng khoảng cách tăng lên thì tốc độ sẽ được cải thiện rất nhiều lần. Lý do thì lee_huynh306 cũng đã giải thích rất rõ.

Multi-thread (và multi-connection) là kỹ thuật chắc chắn được các trình download dùng để tăng tốc độ download. Và do dùng multi-connection cho 1 file nên chắc chắn phải có HTTP-Range của giao thức HTTP để xé nhỏ file cần download. Nếu chỉ dùng HTTP-Range để báo cho server biết cần lấy đoạn nào mà ko có multi-connection thì tốc độ cũng ko có gì khác biệt so với dùng trình duyệt. Thực sự mà nói thì Filefox/IE cũng có hỗ trợ resume ở mức tối thiểu : đang download có thể Pause lại rồi down tiếp, nhưng 1 khi đã Stop thì sẽ ko resume được nữa.


Ngoài ra tôi có thể chắc nhiều bạn đang giảng giải ở đây như chuyên gia nhưng lại chưa từng viết chương trình multi threads cũng như chương trình download
Am hiểu về các kỹ thuật download ko nhất thiết phải từng viết 1 ứng dụng demo download ;)

[scooby]

Được rồi, bạn đúng, tôi nhận sai, được chưa?

Scooby đúng là tên con chó hài đấy. Vui nhé. Khai thác được điều gì hay cho biết thêm với.

Định bi bô mấy câu với hi vọng giúp ai đó thích thì viết flashget killer. Không ngờ bị mang ra đấu tố dữ quá. Tự thấy mình kém, ní nuận không nổi nên rút lui hoàn toàn vậy. Bỏ qua mọi bài của tôi nhé.

Ở đây quá nhiều siêu nhân đấy. Chỉ cần biết 1 là suy được 10 cả ;)

[meotrang7x]

Thực ra multi-thread không phải chỉ áp dụng trên hệ thống 1 CPU. Nếu máy tính có nhiều hơn 1 CPU thì 1 chương trình multi-threading thực sự chạy các câu lệnh cùng lúc với nhau (dĩ nhiên không phải tại mọi thời điểm. Điểm khác biệt duy nhất là các thread chạy trên cùng 1 không gian địa chỉ, nên có thể truy xuất cùng 1 biến (dẫn đến nhiều vấn đề thú vị như dead lock chẳng hạn). Còn xử lý song song thì các process chạy trên các không gian địa chỉ khác nhau.

[quynhlan]

Tính toán (xử lý, lập trình) song song thường chỉ được so sánh với tính toán (xử lý, lập trình) tương tranh chứ không so sánh với multi-threading. Đại khái cũng tương tự như chỉ có thể so sánh "không quân" với "hải quân" chứ không thể so sánh "không quân" với "cơ yếu" bởi vì "không quân", "hải quân" là quân chủng còn "cơ yếu" thì không phải là quân chủng.

Đúng ra, tính toán song song và tính toán tương tranh là 1 chứ không phải là 2 lĩnh vực nghiên cứu riêng biệt. Người ta dùng 2 từ khác nhau là do đề cập đến 2 khía cạnh khác nhau của vấn đề: "song song" hay được dùng khi nói đến khía cạnh phân chia công tác còn "tương tranh" thì hay được dùng khi nói đến khía cạnh phối hợp công tác.

Còn về multi threading, việc phân tích và thiết kế kiến trúc bộ vi xử lí và máy tính hỗ trợ multi-thread, hay phần mềm multi-thread đều sử dụng một phần kết quả nghiên cứu về tính toán song song và tương tranh.

Bởi vậy, nếu nói "một chương trình song song là một chương trình multi-thread" thì có lẽ không ổn lắm, nhưng nếu nói "một chương trình multi-thread là một chương trình song song" thì có lẽ không có gì sai.

[AnhTuanKB]

xài multi-threading :D Cái này thì pascal chịu chết
Cậu này không hiểu gì về multi-thread. Có lẽ đọc qua một vài thuật ngũ rồi lý giải theo cách hiểu của mình. Pascal bây giờ xử lý 3D còn được chứ nói gì thread. Bạn nên thử tìm hiểu freepascal đi.

[=========> Bổ sung bài viết <=========]



Cái này lee_huynh306 cũng đã nói. Ai đã từng học về lập trình đến nơi đến chốn đều biết xử lý song song (parallel processing) và lập trình đa tuyến (multi-threading) là 2 khái niệm hoàn toàn khác nhau. Multi-thread làm cho người dùng thấy có nhiều tác vụ đang chạy đồng thời, nhưng thực tế tại mỗi thời điểm chỉ có 1 tác vụ đang hoạt động (trên 1 CPU). Trong khi đó xử lý song song lại phức tạp hơn rất nhiều, đòi hỏi phải có các thuật toán xử lý song song và ko phải muốn là làm được như multi-thread.

Các giải thích của bạn mơ hồ quá, mulit thread thì đúng rồi, còn xử lý xong xong thì mình chưa hiểu lắm, có lẽ cái bạn muốn nói đến là multi tasking.
Multi tasking tức là đa nhiệm, nó xuất phát từ windows 95 (hình như trước đó Mac đã có rồi). Tức là phân bổ nhiều ứng dụng cùng chạy một lúc, nhưng thực ra tại một thời điễm nhất định thì một chương trình chạy thôi.
Vậy thì nó co gì khác với đa luồng? Mỗi luồng là một tiến trình của ứng dụng, vì vậy một chương trình có thể có nhiều luồng khác nhau, và các luồng này cũng được chạy tuần tự, nhưng phân bổ thời gian thay ca để tạo cảm giác chạy song song.
Dựa trên cơ bản về sự phân luồng đó, người ta tạo ra sự đa nhiệm cho hệ điều hành.
Còn về download, chằng có thuật toàn nào giúp download nhanh hơn được hết. Các chương trình của bạn nằm trên client, và các client này là các terminal nhận dữ liệu từ sever 1 cách thụ động (chỉ được xin và nhận thôi). Nếu sever mà không cấp dữ liệu thì các client cũng bó tay, vì vậy không có xử lý hay thuật tóan nào giúp được download nhanh hơn. Nhưng có một cách là dành quyền ưu tiên, đó là tạo nhiều connect để dành được nhiuều quyền lợi hơn. Khi số lựong connect tăng thì tốc độ chia đều giảm đi, nhưng vì bạn có nhiều connect nên tính ra vẫn lời.
Vì lý do đó một số sever không cho bạn download bằng ứng dụng, vì bạn dành hết băng thông của người ta, chứ nếu có thuật toán đó thì người ta cũng tích hợp vô thiết bị hết rồi, cần gì phải dùng đến chương trình.


Ngoài ra tôi có thể chắc nhiều bạn đang giảng giải ở đây như chuyên gia nhưng lại chưa từng viết chương trình multi threads cũng như chương trình download

Cả 2 cái đó mình đều viết rồi, nếu lập trình .NET thì không cần quan tâm lắm đến trhead, nhưng Java mà không làm thread thì tiêu.
Tuy nhiên 2 cái đó mình chỉ viết ở mức cơ bản thôi, download thì cũng chỉ ở mức FTP. Mấy cái đó viết ra cũng chẳng ai sài.

[=========> Bổ sung bài viết <=========]



Bởi vậy, nếu nói "một chương trình song song là một chương trình multi-thread" thì có lẽ không ổn lắm, nhưng nếu nói "một chương trình multi-thread là một chương trình song song" thì có lẽ không có gì sai.

Hình như bạn này là con gái, mình chưa nghe qua từ "tính toán tương tranh", và 2 cái mà bạn so sánh đó là 2 khái niệm hoàn toàn khác nhau, không thể so sánh kiểu cái này với cái kia hay cái kia với cái này được.

[jiSh@n]

Các giải thích của bạn mơ hồ quá, mulit thread thì đúng rồi, còn xử lý xong xong thì mình chưa hiểu lắm, có lẽ cái bạn muốn nói đến là multi tasking.
Multi tasking tức là đa nhiệm, nó xuất phát từ windows 95 (hình như trước đó Mac đã có rồi). Tức là phân bổ nhiều ứng dụng cùng chạy một lúc, nhưng thực ra tại một thời điễm nhất định thì một chương trình chạy thôi.
Vậy thì nó co gì khác với đa luồng? Mỗi luồng là một tiến trình của ứng dụng, vì vậy một chương trình có thể có nhiều luồng khác nhau, và các luồng này cũng được chạy tuần tự, nhưng phân bổ thời gian thay ca để tạo cảm giác chạy song song.
Dựa trên cơ bản về sự phân luồng đó, người ta tạo ra sự đa nhiệm cho hệ điều hành.
Multi-tasking, multi-threading là những khái niệm thường đi chung với nhau, và nó khác với parallel processing. Parallel phức tạp hơn rất nhiều so với đa nhiệm đa luồng, đòi hỏi phải có các thuật toán riêng biệt để giải quyết những lớp vấn đề khác nhau, để chia khối lượng công việc, chia khối lượng dữ liệu, để sử dụng những ko gian nhớ khác nhau, chạy trên những vi xử lý khác nhau, trên những máy tính khác nhau. Đây là tính toán song song thực sự, chứ ko phải giải lập song song như multi-*. Parallel Processing cực kỳ phức tạp và rất khó để triển khai. Trong khi đó LTV bình thường hoàn toàn có thể viết ra ứng dụng multi-thread trên các hệ điều hành multi-tasking mà ko cần quan tâm nhiều đến các thuật toán phức tạp. Hình như cách đây mấy năm PCWorld VN có đăng 1 bài về xử lý song song đơn giản, nhưng tôi đảm bảo là nó rất khó nuốt đối với rất nhiều LTV ;)

Còn về download, chằng có thuật toàn nào giúp download nhanh hơn được hết. Các chương trình của bạn nằm trên client, và các client này là các terminal nhận dữ liệu từ sever 1 cách thụ động (chỉ được xin và nhận thôi). Nếu sever mà không cấp dữ liệu thì các client cũng bó tay, vì vậy không có xử lý hay thuật tóan nào giúp được download nhanh hơn. Nhưng có một cách là dành quyền ưu tiên, đó là tạo nhiều connect để dành được nhiuều quyền lợi hơn. Khi số lựong connect tăng thì tốc độ chia đều giảm đi, nhưng vì bạn có nhiều connect nên tính ra vẫn lời.
Vì lý do đó một số sever không cho bạn download bằng ứng dụng, vì bạn dành hết băng thông của người ta, chứ nếu có thuật toán đó thì người ta cũng tích hợp vô thiết bị hết rồi, cần gì phải dùng đến chương trình.
Dùng 1 đường tuyền 2 Mbps thì chả có thuật toán hay kỹ thuật nào để có thể đẩy tốc độ download lên 3 Mbps được, nhưng có kỹ thuật để giúp cho tận dụng được toàn bộ 2Mbps của đường truyền. Đó chính là kỹ thuật mà các trình tăng tốc download đang sử dụng giúp cho tốc độ download có thể tăng đến giới hạn tối đa của đường truyền nếu so với cách download bằng web browser truyền thống. Và quảng cáo tăng 400%, 600% tốc độ download của các DM chẳng qua là so sánh với tính năng download mặc định của trình duyệt, ko có thằng náo dám nói là tăng so với đường truyền cả. Và đương nhiên các kỹ thuật này phải bó tay đối với các server áp dụng kỹ thuật hạn chế tốc độ download.

[lee_huynh306]

Bởi vậy, nếu nói "một chương trình song song là một chương trình multi-thread" thì có lẽ không ổn lắm, nhưng nếu nói "một chương trình multi-thread là một chương trình song song" thì có lẽ không có gì sai.

Hình như bạn nói ngược, xử lý song song, tức cùng 1 thời điểm bất kì, có nhiều hơn 1 công việc được xử lý, cái này chỉ có trên những hệ thống nhiều hơn 1 CPU, vì vậy đó chắc chắn là multi-thread, có thể nói xử lý song song (parallel) nó bao gồm luôn cả xử lý đa luồng (multi-thread) trong đó.



Các giải thích của bạn mơ hồ quá, mulit thread thì đúng rồi, còn xử lý xong xong thì mình chưa hiểu lắm, có lẽ cái bạn muốn nói đến là multi tasking.
Multi tasking tức là đa nhiệm, nó xuất phát từ windows 95 (hình như trước đó Mac đã có rồi). Tức là phân bổ nhiều ứng dụng cùng chạy một lúc, nhưng thực ra tại một thời điễm nhất định thì một chương trình chạy thôi.
Vậy thì nó co gì khác với đa luồng? Mỗi luồng là một tiến trình của ứng dụng, vì vậy một chương trình có thể có nhiều luồng khác nhau, và các luồng này cũng được chạy tuần tự, nhưng phân bổ thời gian thay ca để tạo cảm giác chạy song song.
Dựa trên cơ bản về sự phân luồng đó, người ta tạo ra sự đa nhiệm cho hệ điều hành.
Thật ra thì multi-tasking có từ thời DOS chạy trên vi xử lý 8086/8088 rồi.Một số chuyên gia đã viết chương trình chạy trên DOS chặn INT 0x08 (timer) để tạo một môi trường đa nhiệm ảo.
Khi người ta nói multi-tasking có nghĩa là xử lý tùm lum chuyện. Còn khi nói multi-thread có nghĩa là tạo tùm lum thread để xử lý một chuyện.

[quynhlan]

Hình như bạn nói ngược, xử lý song song, tức cùng 1 thời điểm bất kì, có nhiều hơn 1 công việc được xử lý, cái này chỉ có trên những hệ thống nhiều hơn 1 CPU, vì vậy đó chắc chắn là multi-thread, có thể nói xử lý song song (parallel) nó bao gồm luôn cả xử lý đa luồng (multi-thread) trong đó.

Thế khi "trí thức" bao hàm "giáo viên" thì người ta nói "trí thức là giáo viên" hay "giáo viên là trí thức"?

[lee_huynh306]

Thế khi "trí thức" bao hàm "giáo viên" thì người ta nói "trí thức là giáo viên" hay "giáo viên là trí thức"?
Giáo viên là trí thức -> Đúng. Trí thức là giao viên -> Chưa chính xác.
Nhưng mà đừng có hỏi càn hỏi cố. Đang nói về lãnh vực tin học lập trình chứ không phải nói về đời sống thực bạn ạ. Có nhiều cái trong lập trình nó trừu tượng phong phú khác xa thực tế lắm.

[quynhlan]

Giáo viên là trí thức -> Đúng. Trí thức là giao viên -> Chưa chính xác.
Nhưng mà đừng có hỏi càn hỏi cố. Đang nói về lãnh vực tin học lập trình chứ không phải nói về đời sống thực bạn ạ. Có nhiều cái trong lập trình nó trừu tượng phong phú khác xa thực tế lắm.
Hì, QL đã tưởng chỉ cần hỏi vặn lại 1 câu là đủ.

Chính bạn đã nói là xử lý multi-thread được bao hàm bên trong xử lý song song. Nhưng khi QL bảo "chương trình multi-thread là chương trình song song" là đúng còn "chương trình song song là chương trình multi-thread" là không ổn thì bạn lại bảo QL "nói ngược". Lý nào như thế? Ai nói càn nói cố ở đây?

Nói bạn đừng giận nhé, chừng nào mấy thứ rõ ràng như 1+1=2 mà còn chưa thông thì đừng vội nói đến mấy thứ "trừu tượng và phong phú, khác xa thực tế blah blah" làm gì.

[lee_huynh306]

Hì, QL đã tưởng chỉ cần hỏi vặn lại 1 câu là đủ.

Chính bạn đã nói là xử lý multi-thread được bao hàm bên trong xử lý song song. Nhưng khi QL bảo "chương trình multi-thread là chương trình song song" là đúng còn "chương trình song song là chương trình multi-thread" là không ổn thì bạn lại bảo QL "nói ngược". Lý nào như thế? Ai nói càn nói cố ở đây?

Nói bạn đừng giận nhé, chừng nào mấy thứ rõ ràng như 1+1=2 mà còn chưa thông thì đừng vội nói đến mấy thứ "trừu tượng và phong phú, khác xa thực tế blah blah" làm gì.

Tại vì chương trình thiết kế theo kiểu parallel thì chắc chắn là nó có multi-threads. Còn ngược lại, một chương trình multi-threads thì có thể nó không là parallel.
Tôi nói parallel bao hàm multi-thread chứ không hề nói điều ngược lại, mong bạn đọc kĩ lại đoạn chính bạn bôi đen trong bài của tôi.
Và bạn đã nói như thế này


Bởi vậy, nếu nói "một chương trình song song là một chương trình multi-thread" thì có lẽ không ổn lắm, nhưng nếu nói "một chương trình multi-thread là một chương trình song song" thì có lẽ không có gì sai.:noexpress

[vtnphong]

Cậu này không hiểu gì về multi-thread. Có lẽ đọc qua một vài thuật ngũ rồi lý giải theo cách hiểu của mình. Pascal bây giờ xử lý 3D còn được chứ nói gì thread. Bạn nên thử tìm hiểu freepascal đi.


Sorry pro, sau khi xong highschool là mình bỏ pascal luôn rồi :). Mà hồi đó đấu đá chưa được xài freepascal mà chỉ xài đồ của borland thôi nên mình chưa bao giờ thử fp hết.

[AnhTuanKB]

Multi-tasking, multi-threading là những khái niệm thường đi chung với nhau, và nó khác với parallel processing. Parallel phức tạp hơn rất nhiều so với đa nhiệm đa luồng, đòi hỏi phải có các thuật toán riêng biệt để giải quyết những lớp vấn đề khác nhau, để chia khối lượng công việc, chia khối lượng dữ liệu, để sử dụng những ko gian nhớ khác nhau, chạy trên những vi xử lý khác nhau, trên những máy tính khác nhau. Đây là tính toán song song thực sự, chứ ko phải giải lập song song như multi-*. Parallel Processing cực kỳ phức tạp và rất khó để triển khai. Trong khi đó LTV bình thường hoàn toàn có thể viết ra ứng dụng multi-thread trên các hệ điều hành multi-tasking mà ko cần quan tâm nhiều đến các thuật toán phức tạp. Hình như cách đây mấy năm PCWorld VN có đăng 1 bài về xử lý song song đơn giản, nhưng tôi đảm bảo là nó rất khó nuốt đối với rất nhiều LTV

Hiểu rồi!


Nói bạn đừng giận nhé, chừng nào mấy thứ rõ ràng như 1+1=2 mà còn chưa thông thì đừng vội nói đến mấy thứ "trừu tượng và phong phú, khác xa thực tế blah blah" làm gì.

Cưng ơi, con gái thì phải bít nhún nhường, huống hồ cách hiểu của cưng hoàn toàn lệch lạc mà lại đem ra những ví dụ thực tiễn ... sinh động ra để lý giải . "Trí thức" và "giáo viên" không có chút gì tương đồng để so sánh ở đây hết. Bạn không nên tung hỏa mù để làm lêch lạc đề tai như thế, sẽ làm người khác rất khó chịu.

[=========> Bổ sung bài viết <=========]


Sorry pro, sau khi xong highschool là mình bỏ pascal luôn rồi :). Mà hồi đó đấu đá chưa được xài freepascal mà chỉ xài đồ của borland thôi nên mình chưa bao giờ thử fp hết.
Phải, vì nếu học freepascal thì thà học delphi hay hơn. Mà delphi ra ở VN không bết xin được việc không nha!

[jiSh@n]

"Tay to mặt lớn" ở VN mà tuyển Delphi thì tôi biết mỗi SSP, còn mấy công ty bé hơn thì ko rành, mặc dù có kha khá công ty như thế trong Etown lol