※ 本文轉寄自 ptt.cc, 文章原始頁面
看板Soft_Job
標題

Re: [討論] 技術總監有可能不懂BFS嗎??

時間
最新2023-04-29 20:06:00
留言54則留言,10人參與討論
推噓6 ( 7146 )
來單純技術討論一下好了 其實 Visit 也不用限制一定要用 HashMap/HashSet 做 Leetcode 上很多題目的 nodes tag 都是連續的數字或英文字母 這個時候用一般的 Array 效能就會比 HashMap/HashSet 好非常多: 1. 不需動態分配記憶體(感謝一樓提醒) 2. 不需進行 Hash 運算 但也正如同大多數大大所說 一般人的想像場景不會是連續的標籤 在 nodes tag 都不連續的情況下 例如:1, 100, 10000, 1000000, 100000000 這個時候用 Array 就是低能兒了 個人淺見如上 如有錯誤還請各位大大指正 補充 peter98 與 NTHUlagka 底下關於 Hash 的討論(小弟對於 C++ 只能算是略懂,如 果錯誤就再麻煩指正了): 1. 就 C++ Standard Library 對於 HashMap/HashSet 的實作,一開始會先分配一定數量 的 buckets,後續如果超過 loading factor(預設 1.0),再動態增加(std::vecotor 的實作上 一般是加倍)。 2. 關於 Exponential Backoff 與 Bloom Filters 等其他技術,目前尚未實作於 Standa rd Library 裡,所以有需求的話要自行實作。 3. Bloom Filters 可以解放傳統 HashSet 儲存空間帶來的限制,原理很簡單,如果不太 清楚請中文維基就可以輕鬆看懂(一般大學的分散式系統課程也都會教到)。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 138.246.3.10 (德國) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1682195508.A.1B8.html

54 則留言

※ 編輯: leviliang (138.246.3.10 德國), 04/23/2023 04:36:07

plsmaop, 1F
通常效能的差異不在於 hash ,而是不需要一直分配新的記

plsmaop, 2F
憶體
感謝提醒 我居然忽略了這最重要的一環

previa, 3F
主要差異就是在整個解法能不能scale 而已
這也是一個很棒的考量點!

ku399999, 4F
陣列如果資料一直往後放不排序 查詢速度就是n 如果要排

ku399999, 5F
序就要移動大量資料 即使不用分配也快不到哪吧
等等 一般的做法是一個布林陣列然後 node tag 當做 index 因此找 visited node 就是 O(1) 我其實沒很仔細看 Nic 怎麼實作 還是他的實作是你說的方式!?
※ 編輯: leviliang (138.246.3.10 德國), 04/23/2023 08:42:54

s06yji3, 6F
陣列是固定size的東西。如果紀錄的東西是整數,可以直接

s06yji3, 7F
把他當作陣列的index,搜尋就是O(1)

s06yji3, 8F
Nic作法是O(n) XD

s06yji3, 9F
但是後來換成用Set了

peter98, 10F
用hash不代表要一直分配新的記憶體

peter98, 11F
一直動態分配記憶體的不是hash 兩者關係並不大

s06yji3, 12F
嚴格來說你要講HashSet才對。

NTHUlagka, 13F
樓上你hash不動態分配記憶體 那新的值進來你要怎辦 你

NTHUlagka, 14F
一開始不知道要開多大的Hash吧

NTHUlagka, 15F
還是其實C++hash背後也是vector 那就沒事了

a1234567289, 16F
hashmap/set都會牽涉到Load factor 當現在容器裡裝

a1234567289, 17F
了超過一定比例的數量就會自動擴容 但確實hash與否

a1234567289, 18F
和是否動態配置記憶體是兩回事 此外本文的方法一

a1234567289, 19F
也可以視為是一種hashset

a1234567289, 20F
以上自動擴容我講的是現今大多數語言的實作

peter98, 21F
額 s06yji3 看來你真的不董hash用到的vector其動態配置

peter98, 22F
的做法&時機點 建議你找一本簡單的演算法課本讀一下 = =

peter98, 23F
hash會用到動態配置 但是hash如果遇到效能問題 問題根

peter98, 24F
源不是在動態配置 這是兩回事 每次都用動態配置會造成

peter98, 25F
效能問題沒錯 但問題是hash不會出現老是一直需要動態配

peter98, 26F
置 去把大三演算法課本拿出來複習一下 = = 肯定有教

peter98, 27F
靠 at錯人 是NTHUlagka可以去讀一下演算法

peter98, 28F
兩件事 loading factor + 類似exp backoff的作法

peter98, 29F
並不會讓hash有動態配置造成的效能問題

saladim, 30F
Hash還有一些簿記的overhead, 而且長的也有80分像array

saladim, 31F
若是在都要traversal近乎全部的狀況 或許考慮的是nodeId

saladim, 32F
的分布狀況 阿 話說回來 不連續也能弄成連續的 純array

saladim, 33F
還是有其優勢在

NTHUlagka, 34F
喔喔我知道啊 所以我想說如果hash背後是vector的那種

NTHUlagka, 35F
方式擴充就沒事了

NTHUlagka, 36F
是你講的好像沒用到動態配置我才提出疑問怎可能沒用到

NTHUlagka, 37F
實際上是有用到但瓶頸不是在那邊你這樣講不就好了

NTHUlagka, 38F
喔喔沒有是我搞錯少看到一直 當小丑了 抱歉

peter98, 39F
hash背後即使不是vector 也不會有動態配置造成效能瓶頸

peter98, 40F
的問題 現在論文再解決hash效能時 可以看到從來不是在

peter98, 41F
管記憶體配置 極大程度代表動態配置的影響根本微乎其微

peter98, 42F
真正的效能在於hash的設計 以及其查找的方法 最經典的

peter98, 43F
例子就是bloom filter

peter98, 44F
看來NTHU大大是認真討論 我道歉~對不起~剛推文太邱~

NTHUlagka, 45F
我的錯沒看仔細 抱歉 所以瓶頸是在collision 那現在Ha

NTHUlagka, 46F
sh的Hash function都是以bloom filter嗎?還是有更新

NTHUlagka, 47F

peter98, 48F
更正"從來不是"在管記憶體配置 --> "很少"在管

NTHUlagka, 49F
喔喔原來是另一種有別於hash table的資料結構 genius

NTHUlagka, 50F
感謝
感謝各位的討論與分享 資訊量很大我一起整理到本文中 順便把名詞打清楚
※ 編輯: leviliang (138.246.3.10 德國), 04/23/2023 23:09:39
※ 編輯: leviliang (138.246.3.10 德國), 04/24/2023 03:48:50

Lordaeron, 51F

Lordaeron, 52F
們討論的東西的參考。他實作這麼多了,該做總統了....

superpandal, 53F
java的hash不是重點 重點它怎麼解決衝突

superpandal, 54F
這種東西有碰到再研究也不是不可以

leviliang 作者的近期文章

[請益] 不富裕但母親堅持以自己名字買……
預防萬一 請記者不要抄此請益文 小魯弟從小就隨著原生家庭四處漂泊租屋 如今稅後年收約150 可動用資金約80 股票約60-70(尚有未繳清欠債30,一個月需還2) 父母兩人年收共計約120 小妹剛就業 年收約70 個人資產應是尚未累積起來
Re: [請益] GO語言職缺有減少的趨勢?
小弟就職的也算是大型跨國軟體公司 最近因為歐盟等環保政策對於 Green IT 的要求 公司除了舉辦各種 Sustainable Engineering 的課程 也開始探討不同語言的碳足跡與耗能 根據那份產出文件的流程圖 綜合考量環境友善、
[討論] 雞蛋事件關注直接被轉移 台灣完蛋了
雞蛋這麼嚴重的事 出了一個害群之馬轉移掉了關注 媒體側翼像是看到了美味大便的蒼蠅一樣瘋狂地舔 本來當權者就已經在拼命拖延雞蛋的調查進度 現在更是好了 有時間喘氣了 之後甚至連假資料都不用做了 因為有一群犯賤側翼會洗地 而我們等智障島民會忘記
更多 leviliang 作者的文章...