本帖最後由 wldtw2008 於 13-3-19 08:42 編輯
1.我用另一個THREAD來處理下單部份的問題 和我另外寫一個下單機和主程式間用DLL (像下單大師那樣)來下單 那一個的效能可能較好
2.如果是用另一THREAD的方法怎樣在THREAD之間傳遞資訊較佳 比如避免資料的鎖住或互相衝突問題我認為：
1. 應該是自己寫下單較快一點，但也要看您怎麼寫，如果下單的部份是用TIMER去撈訊號是否出現，那就慢了。
2. THREAD間傳遞資料，如眼到手到哥說的，用lock("QueueIO"){queue.push(data) 、 data=queue.pop()} 應該就能處理的很好了。
最後，您問的問題已經涉及了程式架構，很難三言兩語講清楚的。不是不跟您講，實在是不曉得您實力在哪裡、也不曉得您要用什麼樣計算方法，這再再都影響了效能瓶頸。
像眼到手到哥講的，用EXCEL+螢幕截圖+OCR，真的是很有創意的方法，如果可以穩定運行，真的比專程寫ㄧ隻程式去算去寫來的有開發效率，用現存的工具去拼湊出自己要的功能，是大家(包括我)普遍使用的方法。
舉例，以前我抓交易所的資料，是從頭到尾連SOCKET HTTP REQUEST都是自己寫，後來才知道有HTTP LIB可以呼叫，但直到最後才知道有WGET.exe可以用，之後我寫這種抓資料的東西，都是在LINUX下，用SHELL SCRIPT，wget + awk +sed 去完成。快速簡單有效率的打完收工(真的超快，估計程式要寫兩天的東西，兩小時就搞定)
當然，您實際去寫程式，得到的不只是交易的經驗，對於您程式技巧也會有所提升，這是花錢也買不到的，加油了，祝福您!
最後提醒您，MC應該不慢、下單大師也不錯、XDDE我是沒用過不曉得，但是如果XDDE +MC有慢到讓您發覺且難以忍受，那應該是哪裡搞錯了，因為MC+DDE+下單大師，應該是很多人用的解決方案，雖然稱不上最快，但是真的是可以接受的解決方案。
提些意見給你參考
multi-thread實現前通常要先釐清哪些工作是不能被異步執行的~哪些變數或函數是需要同步保護的~thread是polling還是event型的也會影響執行效率
該如何快速實做出整個流程與你的操作策略有關~系統可大可小~為什麼MC會慢就是因為他必須符合大眾的操作策略~
我的經驗告訴我~DDE並不像大家說得那麼容易掉Tick~會掉tick通常是因為執行一個round的時間太長~下一個round執行時已經累積了數個tick~此時就不得已拋下所有的tick只執行最新的一個
如果你的策略屬於價格突破型~若tick的產生沒有造成價格突破~就可以直接拋掉那個tick~節省一個round的時間有機會更早收到下一個tick~類似這樣的作法也能提高效能
---
我也算是傻過來的~甚至比版主更瘋狂~完全摸不清目標
但如果回到當初我一樣會選擇同一條路~
就是因為傻~所以堅持得住~
就是因為笨~所以摸索的更深~
當不願當傻子的人還在找更聰明的方法前~傻子可能已經先馳得點了...
wldtw2008 發表於 13-3-19 08:39 static/image/common/back.gif
我認為：
1. 應該是自己寫下單較快一點，但也要看您怎麼寫，如果下單的部份是用TIMER去撈訊號是否出現，那 ...
我個人猜想應該是有訊號出現才需要把資訊傳給下單THREAD
是不是該用類似EVENT 或是 NOTIFY來作
另外請教 P大"那問題已是.NET Framework的問題了～."
是有何建議嗎
最後再請教J大 非常感謝您的分享
因為怕JAVA在WIN下執行慢 所以沒考慮用JAVA (雖然基本的我會)
但我看一下JAVA和C#是很接近的
您是高手是否能願意進一步給些建議 讓小弟不多走冤枉路
就是說該用那一種JAVA的方式來傳遞訊息
這些訊息原則上應該是被保護 當執行完後再執行新的
也就是當有訊號出現 通知另一THREAD 這THREAD先處理這訊息
我的K棒主程式繼續接收DDE TICK
除非停損條件成立 不然要等下一K棒才會有新的訊號通知下單THREAD
如果在INTRABAR一直有訊號
因為我的策略是採突破停損處理INTRABAR的停損
基本上除非上上下下跳很快 不然是不容易在INTRABAR出現三次以上的停損
那才會通知下單THREAD 但是 必須LOCK 目前的K棒 避免被修改
但是當K會存目前的訊號 在下單機是不會修改目前的訊號
我目前作法是下單後就假設已經下單成功 因為用市價單
所以訊號是不會消失只等停利 停損 或反手單
感謝各位的分享 指點
jinace 發表於 13-3-19 10:25 static/image/common/back.gif
提些意見給你參考
multi-thread實現前通常要先釐清哪些工作是不能被異步執行的~哪些變數或函數是需要同步 ...
J大及其他幾位程式高手大大
請教"multi-thread實現前通常要先釐清哪些工作是不能被異步執行的~哪些變數或函數是需要同步保護的~thread是polling還是event型的也會影響執行效率
該如何快速實做出整個流程與你的操作策略有關~系統可大可小~為什麼MC會慢就是因為他必須符合大眾的操作策略~"
我是猜 EVENT型是不是效慮較佳
可是回傳主程式該用那一種不會影響效能
謝謝
jerrywang168 發表於 13-3-19 11:54 static/image/common/back.gif
J大及其他幾位程式高手大大
請教"multi-thread實現前通常要先釐清哪些工作是不能被異步執行的~哪些變數或 ...
大致敘述一下~你可以參考
假設用兩個thread,一個tick thread用來處理tick發生時的事件,另一個act thread處理K棒指標與交易邏輯
基本上兩個thread可能同時執行~也可能同時不執行~但絕不能重疊執行(例如同一時間兩個tick或兩個act thread)
tick thread用tick event來觸發,act thread則靠tick thread決定是否觸發
tick thread應該可以靠上層的tick event來達到同步,不需特殊處理也不會發生重疊執行的問題(除非event也是異步)
act thread可以放在單一執行的thread pool裡~使其不會被重疊執行~並嘗試迅速的執行到最新的thread
我說得不全然能套用在你的實做上~就一個大概的輪廓
先求有再求好吧~有大致的架構再慢慢修~不可能一步到位的
本帖最後由 眼到手到哥 於 13-3-19 13:19 編輯
wldtw2008 發表於 13-3-19 08:39 static/image/common/back.gif
我認為：
1. 應該是自己寫下單較快一點，但也要看您怎麼寫，如果下單的部份是用TIMER去撈訊號是否出現，那 ...
是阿~~ 超穩的喔~~
之前為了擷取螢幕, 用了很多現成的軟體~~ 但只有一套勉強能符合我的需求~~
可是程式不穩, 常常跑到一半就掛掉,
沒法度~~ 只好自己寫~~
jinace 發表於 13-3-19 13:00 static/image/common/back.gif
大致敘述一下~你可以參考
假設用兩個thread,一個tick thread用來處理tick發生時的事件,另一個act thread ...
謝謝您方享
那我用BACKGROUNDWORKER(好像是C#專有)來試看看
(因為畢竟這部份我比較不熟)
感謝
眼到手到哥 發表於 13-3-19 13:08 static/image/common/back.gif
是阿~~ 超穩的喔~~
之前為了擷取螢幕, 用了很多現成的軟體~~ 但只有一套勉強能符合我的需求~~
可是程式不 ...
請問眼大，那您OCR是怎麼作的? 有LIB可以呼叫??
OCR是很成熟的應用了，十幾年前很火，最近幾年沒啥聽人在講了。
wldtw2008 發表於 13-3-19 14:31 static/image/common/back.gif
請問眼大，那您OCR是怎麼作的? 有LIB可以呼叫??
OCR是很成熟的應用了，十幾年前很火，最近幾年沒啥聽人在 ...
噓~~小聲點~~去找谷歌大神~~
有好料的~~ 不過還需要自己再修正過才能用~~
{:5_232:}
jinace 發表於 13-3-19 13:00 static/image/common/back.gif
大致敘述一下~你可以參考
假設用兩個thread,一個tick thread用來處理tick發生時的事件,另一個act thread ...
我覺得~~ 處理K棒的thread可以用timer來處理, 比如說一秒鐘更新5次, 對人的眼睛來說已經快到跟不上了,
不然....萬一快市..... 那處理K棒的thread不就要忙死了...
{:5_256:}
利用Timer來處理？是否會因不斷去計算時間而增加CPU使用量？
個人是利用收到一個TICK就去Trigger Event，沒有掉TICK也沒有DELAY。
除了 order update, Tick 恐怕是trading platform 裡最基本要做的事，當然要給他最高優先權！
從一個完整的trading platform 眼光來看，必須要有完整的event 處理模式。下面是Ninjatrader 第一層的event handlers： 這些event hooks 可以讓你控制你的策略，細到， Level 2 bid/ask 改變都可以做動作，因為，可能bid/ask 變了，但是還沒有成交的ticks.
另外，如果你下單，任何order 狀況的改變 （partial fill, rejected, etc) 都是從 OnOrderUpdate 處理。 成交了 是由 OnExecution 處理，這裡你可以加你的 停損 order, 或是 trail stop order.
OnConnectionStatus() - Called when a connection state changes
OnExecution() - Called when a strategy generated order is filled<---- 1
OnFundamentalData() - Called on any change in fundamental data
OnMarketData() - Called on any change in a level 1 market data stream
OnMarketDepth() - Called on any change in a level 2 market data stream
OnBarUpdate(）- Called when the price bar changes with incoming data <---- 1
OnOrderUpdate() - Called when a strategy generated order changes state<--- 1
OnPositionUpdate() - Called when a strategy generated position changes
OnStartUp() - Called once when a script first starts up
OnTermination() - Called once when a script is terminated
眼到手到哥 發表於 13-3-19 14:43 static/image/common/back.gif
我覺得~~ 處理K棒的thread可以用timer來處理, 比如說一秒鐘更新5次, 對人的眼睛來說已經快到跟不上了,
...
1秒更新5次~也就是說0.2秒才更新一次~別的延遲不算就已經輸0.2秒了
0.2秒用肉眼觀察其實是很明顯可以分出快慢的
不多做點運動CPU會感冒的...
balance 發表於 13-3-19 17:33 static/image/common/back.gif
除了 order update, Tick 恐怕是trading platform 裡最基本要做的事，當然要給他最高優先權！
從一個完整 ...
高手高手高高手~~
完整的模組化處理~~~
佩服佩服
{:5_260:}http://www.coco-in.net/static/image/smiley/cwwany/35.jpghttp://www.coco-in.net/static/image/smiley/cwwany/35.jpg
balance 發表於 13-3-18 19:45 static/image/common/back.gif
這裡還真是高手如雲。。。
不過前人說的很好，還是集中在策略。英文有句話，叫做 'reinvent the wheels'....
在 iPhone 之前, 市場上已經有 smart phone 了但是賈伯斯堅持 reinvent smart phone, 結果顛覆市場, 大成功
也許開版主有遠大的志向, 值得鼓勵