in

Darkthread

黑暗執行緒

Browse by Tags

  • 在.NET 3.5中使用Parallel.For()

    網友 KENCHAO 問到" 好威的Parallel.For 可以用在.NET 3.5上"嗎? 微軟在Task Parallel Library CTP版本時代 ,曾提供過相容於.NET 3.5的Microsoft Parallel Extensions for .NET Framework 3.5。但找了一下,官方似乎已不再提供該版本的下載... 但是別氣餒,依據MS Parallel Programming RD小組在2009年11月的PO文,有一個來自個 DevLabs 的替代解決方案-- Reactive Extensions to .NET (Rx),其中有個System...
    公佈在 黑暗執行緒 (Weblog)Jeffrey 發表於 02-05-2010
  • 用.NET展現多核威力(3) – 佛心TPL之Parallel.For好威

    在 前一篇文章 裡,我們驗證了為每個CPU Core開一條獨立Thread並事先分攤好計算工作,可以讓巨量Log10計算程式飆出最高效能! 但是,仔細看看程式碼: int WORKER_COUNT = 2; Thread[] workers = new Thread[WORKER_COUNT]; int jobsCountPerWorker = MAX_COUNT / WORKER_COUNT; for ( int i = 0; i < WORKER_COUNT; i++) { int st = jobsCountPerWorker * i; int ed = jobsCountPerWorker...
    公佈在 黑暗執行緒 (Weblog)Jeffrey 發表於 01-21-2010
  • 用.NET展現多核威力(2A) - 一核一緒補充包

    在 前一篇多核研討文章 中,用了一個計算1000萬次Log10運算的範例驗證Thread數與Core相同時可以達到最佳效能,網友Google質疑以Log10計算當範例是否用能代表"以運算為主的大量作業",在此做點補充說明。 我想若以茶包射手實事求是的精神,"以運算為主的大量作業"這個命題是有問題的,應該要修正成"不涉及非CPU資源競爭的大量純運算作業"更貼近原意。用白話來解釋,這裡假設的前題是---有一大堆運算工作要處理,每件運算工作彼此獨立可以同時進行,且每件運算所需的資料自給自足,不需要排隊讀取/寫入記憶體、磁碟、網路等資源。當此前題成立...
    公佈在 黑暗執行緒 (Weblog)Jeffrey 發表於 01-19-2010
  • 用.NET展現多核威力(2) - 一核一緒 王者之道?

    在 前一篇文章 裡,我們陰了ThreadPool一下,把一個運算十分簡單,但是數量極其龐大的計算需求拆解成無數UserWorkItem交給ThreadPool執行,然後冷眼旁觀ThreadPool在lock機制的消磨下,慘敗給傻瓜都會的單一執行緒寫法,速度足足慢了七倍有餘... lock機制看來是最大的殺手。明明人手充足,卻規定所有人員必須排隊成一列輪流完成某個動作才能繼續工作,當完成工作本身所需的時間很短,則耗費在排隊的時間就顯得漫長而荒謬。這就是前一篇文章所點出的事實。 那麼,在這個案例中,我們應如何改善? 概念很簡單---讓所有可用的CPU資源都專心投入在執行運算上,避免花費任何額外資源去處理不必要的工作...
    公佈在 黑暗執行緒 (Weblog)Jeffrey 發表於 01-02-2010
  • 用.NET展現多核威力(1) - 從ThreadPool翻船談起

    在進入主題前,先來爆個料: 踢爆黑心程式碼,瞎忙半天幫倒忙!! 昨天我貼了一篇關於 匿名方法與具名方法效能比較 的文章,不知有沒有人發現到,其實裡面藏了一個天大的祕密!! Lambda寫法無損效能的結論是對的,但是,在這個範例裡用ThreadPool處理卻錯得離譜! 不信? 那我們先保留第二段的ThreadPool + Lambda寫法,但將第一段改成 for (int i = 0; i < TIMES; i++) NamedMethod(i); 換句話說,第一段程式不再管什麼鬼ThreadPool,直接用迴圈把1000萬次做完。執行的結果可能會讓你大吃一驚: Named Method ...
    公佈在 黑暗執行緒 (Weblog)Jeffrey 發表於 01-01-2010
  • Try Catch Block是否會影響效能?

    跟網友在部落格上討論效能時提到一個 議題 --在迴圈中加入try...catch是否會影響效能? 依我的認知,try...catch只有在發生Exception時才會 嚴重危害效能 ,平時正常執行時,我們倒可以"幾乎忘了它的存在"。 不過,我過去似乎還真沒用測試驗證過這一點,既然聊到了,就順手寫幾行Code實測一番: using System; using System.Diagnostics; namespace TryCatchCost { class Program { static void Main( string [] args) { Stopwatch sw ...
    公佈在 黑暗執行緒 (Weblog)Jeffrey 發表於 12-20-2009
  • LINQ to XML vs XPath的簡單效能測試

    如果你使用的平台是.NET 3.5,在操作XML文件時會有三種選擇: LINQ to XML, LINQ to XML with XPath以及傳統的XmlDocument。既然有三種選擇,排除個人主觀偏好,想知道哪一種做法的效能最好呢? 之前有個迷思,一直覺得LINQ表達方式友善,理論上會付出效能上的代價(正所謂有一好沒兩好)。所以有時針對複雜的元素查詢,我會using System.Xml.XPath,然後改用XPathSelectElements()查詢,直到無意間發現了一篇 談LINQ to XML與XPath Benchmark 的文章,才發現我錯了。該文作者試了一個120,000筆資料...
    公佈在 黑暗執行緒 (Weblog)Jeffrey 發表於 12-15-2009
  • 觀察LINQ to SQL DataContext的連線開啟時機

    昨天的文章 發表後,有兩位網友提到了DataContext是否要加using的議題。 我接觸LINQ to SQL是由Scott Gu的 這幾篇文章 開始入門的,在他的範例中沒有特別提到using,我也自始就忽略DataContext有實做IDispose這件事。雖然用using包住絕對有益無害(只要小心using中間過程如將DataContext傳到外部,要留意using結束後外部就不可再繼續叫用),但我倒認為DataContext裡的Connection應該不是一new DataContext就建立一條連線不放,直到Dispose()才結束釋出,而是Query時開啟連線,用完即關閉;Update時再重新開啟連線...
    公佈在 黑暗執行緒 (Weblog)Jeffrey 發表於 10-18-2009
  • 文章-StringBuilder與String的字串相接效能大車拼

    一直以來,我對StringBuilder懷有很深的歉意。 明明StringBuilder在設計上,就是針對String在字串處理上的無效率做了諸多改良,偏偏在本站幾次登場: 要不就是在靜態字串相接上 輸到灰頭土臉 ;再不就是在Replace比試中 陰溝裡翻船 。被不熟.NET的人瞧見了,還誤以為StringBuilder是隻紙老虎哩... 在此鄭重聲明,StringBuilder真的是鐵打硬漢,只是剛好前述的兩個案例比的是繡花跟炒菜,所以才.... 在 StringBuilder串接字串的迷思 一文中,我提到了要為StringBuilder 寫一篇平反文 。後來我也真的在RUN!PC發表了一篇文章...
    公佈在 黑暗執行緒 (Weblog)Jeffrey 發表於 09-06-2009
  • 從LINQ to SQL的"一行更新法"聊起

    我喜歡LINQ to SQL的簡潔,就拿更新資料庫某筆資料這件事來說,你可以忘記SqlConnection、丟掉SqlCommand、抛下SqlParameter,就搞定整個更新動作,對寫慣ADO.NET的人來說,實在是件不可思議的事。 像下面這個例子,寫一段LINQ配上Single()取得資料物件,重新指定值,然後SubmitChanges()就完成了ID=2 Player資料的CreateTime欄位更新。有種袖子都還沒捲起來,敵人就忽然自已暴斃的莫名爽快。 protected void Page_Load( object sender, EventArgs e) { PlaygroundDataClassesDataContext...
    公佈在 黑暗執行緒 (Weblog)Jeffrey 發表於 07-13-2009
第3頁,共4頁 (39個項目) < 上一頁 1 2 3 4 下一頁 >
Powered by Community Server (Non-Commercial Edition), by Telligent Systems