Ứng dụng của FPGA trong ngành tài chính

[jefflieu]

Nhưng thấy ông jefflieu thì thay đổi quan điểm đến chóng mặt đến nỗi không ai có thể xác định là quan điểm của jefflieu trong vấn đề này và anh ta có hiểu những gì mà mình nói hay không ( hay là quan điểm của jefflieu là gió chiều nào theo chiều ấy nhỉ ).

Mình thay đổi quan điểm gì?
Cũng lạ là mình cũng có ý nghĩ như ITX, không biết ông ITX có biết những gì ổng nói hông ...
Haiz, chỉ có cách đổ thừa cho môi trường Forum này không thích hợp cho việc tranh luận thế này.
Thôi thì gác kiếm vậy.

[falleaf]

Giờ thì đã hiểu rồi:
- Jefflieu có ý đúng, nhưng chưa hiểu rõ "monte-carlo" gì đó. Thực chất Monte-Carlo chỉ là một thuật toán thống kê, công thức toán cũng đơn giản thôi, không có gì phức tạp cả. Nó sẽ sử dụng dữ liệu đã có để tính toán và thống kê. Cuối cùng nó cũng không vượt ra khỏi cái mà F nói đó là tính toán mấy cái trung bình, phương sai. Đồng chí nào muốn tìm hiểu mấy cái của nợ này trong ngành hệ thống năng lượng thì qua đây F cho mượn sách. Cái này bọn Mỹ nó dùng để giám sát và đánh giá hệ thống, cũng như chuẩn đoán bảo trì, hoặc tính toán xây dựng hệ thống. Cái của nợ này cũng dùng trong robotics nữa. Dùng trong tài chính thực chất là không khác gì, bởi vì cuối cùng rồi mấy đồng chí này cũng chỉ là các thuật toán thống kê.

>> Cái này F đồng ý ở điểm, đó là các bài toán này là dạng bài toán nhỏ, nhưng vấn đề chính là cái phần "lưu trữ dữ liệu" và "truy xuất dữ liệu" cho nó, thì nó ở mức độ nào? Thực chất mà nói, việc tính toán và xử lý các công thức ở đây sẽ không tốn nhiều thời gian bằng việc truy xuất dữ liệu. Bởi bài toán thống kê phụ thuộc vào số liệu đã có. Cái này có thể FPGA có lợi thế.

- Nói về nhúng hay không nhúng

>> Nếu tranh cãi FPGA có thuộc hệ thống nhúng không, thì khẳng định là có. Còn tranh cãi thì không tranh cãi, vì nó lại liên quan tới mấy ông đã đẻ ra ngành "Hệ thống nhúng" của cả quốc tế lẫn Việt Nam. Bởi vì nếu tranh luận nhúng hay không nhúng là phải từ quan điểm của mấy ông này. Chúng ta cũng không cần bàn cãi, vì nó cũng tùy quan điểm nghiên cứu.

- Vấn đề mấu chốt:
>> FPGA tiết kiệm năng lượng hơn PC/Server, và mức tiêu thụ năng lượng ngang ngửa với DSP/DSC/MCU (cái mà ta chẳng cần tranh luận cũng gọi nó là nhúng).
>> FPGA tính toán nhanh hơn DSP/DSC/MCU và thua PC/Server, ta có thể khẳng định thua PC/Server là đúng, còn so với DSP/DSC/MCU thì còn tùy loại ứng dụng. Coi như chẳng mèo nào cắn mỉu nào. Vd như nói những ứng dụng dạng LCD controller, thì rõ ràng FPGA có lợi điểm hơn, nhưng nếu nói là tính toán xử lý dữ liệu thì trên nguyên tắc nhà thiết kế muốn làm thì sẽ làm được từ FPGA, nhưng làm tới khi nào thì được như mấy cái cục DSP engine thì còn chấm hỏi. Trong tranh luận này, cứ cho rằng các bài toán thống kê mà FPGA thực hiện có tốc độ cao hơn DSP/DSC thông thường.

Vậy vấn đề ở chỗ, sử dụng nó như thế nào?
>> Rõ ràng nếu không gặp trở ngại về vấn đề năng lượng thì FPGA chẳng chơi được với PC.
>> Nếu gặp trở ngại ở vấn đề năng lượng, thì lúc này mới cân nhắc giữa DSP và FPGA.

Điểm lý tưởng ở chỗ là ta có thể gắn mấy cái "Monte-Carlo gì đó" vào con FPGA như một chức năng đặc biệt (giống kiểu PWM cứng so với PWM mềm) thay cho việc tính toán thuật toán trên DSP.

Vậy vấn đề là cái này có đủ thuyết phục chưa về mặt giải pháp:
- Một giải pháp khác với giải pháp đang có thì phải nhanh hơn, mạnh hơn, giảm chi phí hơn
a) Giảm chi phí hơn: còn nghi vấn
b) Nhanh hơn: tạm coi là nhanh hơn, vì coi như đó là function cứng.
c) Mạnh hơn: mang cả nghĩa linh hoạt hơn và có thể áp dụng đại trà hơn, cái này thì FPGA yếu thế hơn. Bởi DSP có thể linh hoạt về thuật toán (thay đổi dễ dàng), và áp dụng đại trà thì DSP "ready to ship" tới mức hàng triệu chip, trong khi đó FPGA thì khả năng áp dụng đại trà chắc chắn kém hơn, trừ khi làm ra con chip fixed function. Upgrade firmware từ xa như ăn kẹo.

Cái chỗ nói "nhanh hơn" chính là chỗ tranh cãi, nhưng theo F, nếu chỉ vì nhanh hơn thì chưa đủ để kết luận người ta sẽ dịch chuyển sang FPGA. Do vậy, có lẽ Jefflieu nên tìm thêm một số tài liệu tham khảo khác, chứng minh các tính chất Scalable, Flexible, Competible, Robust, Stable, Upgradable, của FPGA trong ứng dụng "Tài chính", đồng thời chứng minh được tính "Tài chính (hiệu quả kinh tế)" của việc sử dụng FPGA, thì có lẽ nó sẽ mang tính thuyết phục hơn.

>> Chúng ta mới chỉ tranh luận trên "phỏng đoán" và "quan điểm"... chưa ăn thua.

>> Tại sao Jefflieu nên đi tìm, bởi vì "phe" ủng hộ DSP thì tất nhiên không bao giờ viết bài báo "ứng dụng DSP vào ngành tài chính, vì có thể nói nó đã được dùng rồi". Vậy thì "phe" ủng hộ FPGA phải chứng minh rằng hiệu quả kinh tế nó cao hơn, thì mới có tính thuyết phục cộng đồng phát triển xu hướng nghiên cứu này.

Chúc vui

[nhathung1101]

Tại sao cứ phải "ứng dụng FPGA trong tài chính" nhỉ? Sao không nghiên cứu ứng dụng FPGA trong y tế đi?

Tớ thấy rõ ràng FPGA rất mạnh trong việc làm các MOD nổi nóng, mất bình tĩnh trong tranh luận... Nếu nghiên cứu làm thuốc cho bọn đi nghiên cứu Nam cực chắc là tốt lắm.

[quoc_thaibk]

Tại sao cứ phải "ứng dụng FPGA trong tài chính" nhỉ? Sao không nghiên cứu ứng dụng FPGA trong y tế đi?

Tớ thấy rõ ràng FPGA rất mạnh trong việc làm các MOD nổi nóng, mất bình tĩnh trong tranh luận... Nếu nghiên cứu làm thuốc cho bọn đi nghiên cứu Nam cực chắc là tốt lắm.

Anh cầm cần câu về quê em thả rê cá lóc dính chắc nhiều lắm đây. hehe

[itx]

Công nhận bác F càng ngày càng lẩm cẩm ;D . Có phe nào ủng hộ DSP đâu, lấy DSP ra làm ví dụ mà bác F .
Vì khi tính toán theo kiểu này con fpga đã trở thành một con dsp mềm.

Nếu bạn nhình vấn đề bài toán mà bạn ví dụ thì nó na ná DSP và nó cũng có hạn chế, ưu điểm như DSP vậy.
Khi sử lý tính toán số học như đơn giản như ***** Security RFID hặc như www.xtremedatainc.com thì còn được (cái này DSP làm từ lâu như chuyển đổi CODEC, SSD... ) . Nhưng khi mở rộng bài toán ra như những việc mà các CPU đang làm thì đó là việc bất khả thi giống như với DSP vậy.

Nhưng jefflieu muốn dùng FPGA làm HPC ( trích đánh giá của bqviet). Không phải là loại CPU+DSP như CUDA của nvidia đang nổi đình nổi đám hiện nay.

Mình nghĩ việc gọi CPU trên FPGA cần được hiểu rộng như thế này:
Không phải CPU trên FPGA giống y hoặc gần giống cấu trúc của CPU thông thường. Nếu vậy sẽ không có gì đáng bàn cãi, CPU thông thường làm bằng ASIC, chạy 3-4GHz, có tới 2 cache. Microblaze và Nios chỉ là đồ chơi.
Nhưng CPU trên FPGA có được lợi thế đặc chế, có nhưng dòng lệnh CPU thực hiện nhiều clock nhưng CPU đặc chế thực hiện 1 clock, lấy ví dụ như DSP và GPU là 2 CPU đặc chế cho 2 thị trường. Ngoài ra mình nghĩ các server cũng sẽ có CPU riêng, các router cũng sẽ có CPU riêng. Vá cũng có thể mấy nhà khoa học NASA cũng sẽ có CPU riêng.

Nếu như thị trường phân tích tài chính lớn, thì chắc cũng sẽ có dòng CPU cho riêng thị trường này rồi không chờ thăng xtremedata làm tren FPGA làm gì.

[jefflieu]

Rồi oke, oke.

[tonyvandinh]

Về vấn đề dùng FPGA hoặc ASIC để tăng tốc độ tính toán và giảm năng lượng tiêu dùng, tổng hợp mức cao (High Level Synthesis) đang được phổ biến cho vấn đề này. Các bạn có thể xem bài dưới đây để biết thêm chi tiết.

http://www.altera.com/literature/wp/wp-aghrdwr.pdf

Chào

[nemesis21]

Sau một hồi phản biện, ngoài việc khẳng định lại vốn kiến thức cũ, các bạn đã nghiệm ra được điều gì mới?


Tôi thấy bạn MinhHa đề cập đến embedded CPU trong FPGA chỉ có 1 FPU. Nhìn sâu hơn một chút, latency của FPU khoảng 3-4 clock cycles. Thêm vào CPU overhead để move data chẳng hạn, thì may mắn lắm chúng ta mới có được khoảng 1 floating point operation mỗi 5 cycles. FPU đó đại khái chỉ để làm kiểng.

Xin mạn phép nhắc lại: embedded CPU như MicroBlaze có thể kết nối với các co-processors. Mỗi co-processor có thể là 1 FPU, hoặc là multiple FPUs kết hợp lại để implement một function cao hơn. Lý thuyết là như thế, nhưng thực hành như thế nào?

MicroBlaze kết nối với co-processors qua PLB hoặc FSL. Khi MB write data đến co-coprocessor qua PLB/FSL, nói chung là có overhead (thí dụ như for loop overhead, memory address computation overhead, vv) và chỉ có để chuyển được 1 32-bit word mỗi vài clock cycles. Nếu chúng ta có 16 co-processors @250MHz, và mỗi co-processor có thể perform multiple floating point operations per cycle, nhưng CPU @ 100MHz chỉ có thể chuyển 1 data word mỗi vài clock cycle, thì bottleneck ở đâu chúng ta đều có thể nhận ra.

Một mẹo nhỏ, và cũng là một mấu chốt để giải quyết vấn đề, là chúng ta không dùng PLB/FSL để chuyển data đến các co-processors. PLB/FSL nên được dùng để chuyển counterpart của data. Còn data thì như thế nào? Làm thế nào để co-processors access processor's data @1400MB/s (350MHz x 4-byte)? Hoàn toàn có thể làm được dựa vào những concept cơ bản đã được đề cập đến, và nếu bạn tìm hiểu một chút về cấu trúc của MicroBlaze. Chỉ cần một vài mẹo vặt, nhưng phải think outside the box, đừng dựa vào cấu trúc default. Làm thế nào để access data @2800MB/s? Đến lúc này bạn không thể hoàn toàn dựa vào EDK GUI, mà phải modified phần EDK-generated code một chút. Sau đó, tăng lên 5600MB/s hoặc 12600MB/s hoặc hơn nửa cũng không thành vấn đề khi bạn nắm được mẹo vặt đó. Một chút gợi ý nằm trong ratio 1400/2800/5600/12600.

Cũng đừng quên rằng chúng ta có thể instantiate multiple MicroBlaze. Đến lúc đó thì việc viết HDL để tạo ra các co-processors nhỏ gọn rất quan trọng. Lúc trước tôi đã có đưa lên vài tutorial về thủ thuật với SRL16 để code synthesize gọn hơn. Còn những thủ thuật khác, nhưng nhìn chung thì đại đa số các bạn trẻ vào sub-forum FPGA chỉ để hỏi về bài tập, và sau đó thì ra đi không trở lại.

Đây mới là chỉ ra MicroBlaze không yếu như khá nhiều bạn đã nhận định. Bắt đầu với một việc đơn giản như MicroBlaze + co-processors, trên lý thuyết thì ai cũng tự cho rằng đã biết, nhưng còn phải xem các bạn thực hành như thế nào cho có hiệu quả. Nếu các bạn chưa thực hành thành thạo và hiệu quả một việc đơn giản, rất khó để các bạn đánh giá chính xác những vấn đề complex hơn.


Còn so sánh CPU vs FPGA (chưa đụng đến DSP), ai "mạnh" hơn là vấn đề khác. Những thông số về GFLOP chỉ mang tính tương đối. FPGA không vượt trội về floating-point, nhưng CPU cũng không. Nhưng trong các thuật toán, double-precision có luôn luôn cần thiết? Người ta luôn compare giữa floating point và fixed point implementation, và đưa ra lựa chọn tùy theo sai số. Precision bits của DSP48 (36-43-48 precision bits) nằm giữa single-precision (23-bit fraction precision) và double-precision (52-bit). Cần 10-12 DSP48 để tạo thành 1 FPU, nhưng khi double-precision không cần thiết thì cán cân nghiêng hẳn. Còn những vấn đề kỹ thuật ngoài những điểm casual đã được nêu ra.


Nói chung là, một người thông thạo hàng chục ngôn/ngoại ngữ, nhưng cả đời chỉ khẳng định cây chuối chỉ hữu dụng với những quả chuối. Nhưng một người nông dân chẳng hạn, lại biết rằng cây chuối hữu dụng từ quả, bắp, củ, lá, bẹ, lõi, đến hột. Khi một số nhà ngôn ngữ học không có điều kiện tiếp cận phản biện với một vài anh nông dân về ứng dụng của cây chuối, trong giới hạn của diễn đàn này thì kết luận có lẽ sẽ mãi vẫn lẫn quẫn như cũ.

[tonyvandinh]

Mỗi co-processor có thể là 1 FPU, hoặc là multiple FPUs kết hợp lại để implement một function cao hơn. Lý thuyết là như thế, nhưng thực hành như thế nào?

Mỗi một FPU, khi hoạt động có thể mất hơn 1 cycle. Ví dụ như để làm một bài toán dưới đây:

out = (a*b)+(c*d)+(e*f);

Giả thử mỗi cái nhân (*) mất 5 chu kỳ, mỗi cộng (+) mất 1 chu kỳ thì tổng số chu kỳ cho bài toán này mất ít nhất 17 chu kỳ. Để rút ngắn thời gian, nếu co-processor có 3 nhân (*) và 1 cộng, 3 tính nhân có thể chạy song song để rút ngắn thời gian lại và tổng số chu kỳ sẽ là 7 chu kỳ. Cộng không cần 2 cái vì số thành của tính cộng sau lệ thuộc vào tính cộng đầu. Nếu co-processor có pipeline multiplier (tính nhân nối hàng?) thì số thành đầu tiên của bài tính là 7 chu kỳ nhưng những số thành kế tiếp có thể ra sau cái đầu 1 chu kỳ mà thôi. Kỹ thuật này thường được dùng trong DSP hoặc GPU (Graphics Processor Unit).

Chào
Tony