Re: [面試] AMI面試主管真是佛心來著

看板Tech_Job作者 (800IM)時間11年前 (2013/01/12 09:50), 編輯推噓14(18推 4噓 41→)
留言63則, 16人參與, 最新討論串5/7 (看更多)
推
01/12 02:36,
我剛用gcc試了一下，兩種寫法翻出來的ASM是一樣的
01/12 02:36
→
01/12 02:37,
這樣犧牲可讀性的寫法真的有比較好? 我也寫過MCU,也知道
01/12 02:37
→
01/12 02:51,
可能是我搞錯啦~只是不曉得原原PO有沒有驗證過到底省多少?
01/12 02:51
用 keil 3 編出來的組語,如果只有 if(敘述式) V.S. (敘述式)&& 的確一樣。 但是我當初的狀況，其實是要對N為奇數或偶數，做不同運算， 所以我比較 「if-else if」 V.S. 「()&& !()&&」兩種語法的組語 後者雖然少一行，但我對組語不熟，也不敢99.9%說少這一行就比較快， 所以貼上來讓大家公評，如果後者沒比較快，我就為此事道歉 code compare http://i.imgur.com/pHv26.png
如果要說後者code style不符合某些業界的習慣，造成團隊效率降低我承認， 我並非有業界經驗的人，他們可以對新人這樣要求，或說即戰力不高， 但以此評價新人的長期能力則會失準 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.122.165.222
推
01/12 09:54, , 1F
是說對組語不熟，當初怎麼評斷這樣效率有沒有比較好?
01/12 09:54, 1F
以對組語粗淺的知識來判斷
→
01/12 10:09, , 2F
P2是奇數的話,應該左邊比較快.中間就直接ret了.
01/12 10:09, 2F
→
01/12 10:09, , 3F
而且不是奇數當然就是偶數..幹嘛判斷兩次..
01/12 10:09, 3F
→
01/12 10:11, , 4F
是說左邊應該不需要第2個if吧 P2&1 不是0就是1 else就好了..
01/12 10:11, 4F
→
01/12 10:12, , 5F
樓上無誤..
01/12 10:12, 5F
→
01/12 10:13, , 6F
結論...原PO的code跑更慢~~~~~~~~~~~~~~~~~~~~~~~~
01/12 10:13, 6F
if elseif 8行 && !()&& 7行 if else 6行 很抱歉，我左右兩邊都是更慢的 但是請勿失去焦點， 最初的爭議還是在 AMI 主管認為「短路運算子」和「逗號運算子」根本不合法
→
01/12 10:33, , 7F
除非你能肯定沒有更好的寫法，不然有時候compiler
01/12 10:33, 7F
→
01/12 10:33, , 8F
本身的優化是更好的
01/12 10:33, 8F
推
01/12 10:58, , 9F
其實大家在這過程中都進步了 原PO還是給了大家討論的發展空間
01/12 10:58, 9F
※ 編輯: deo2000 來自: 140.122.165.222 (01/12 11:10)
噓
01/12 11:09, , 10F
只不過比面試主管多懂一個冷門又不實用的寫法 就上來酸他
01/12 11:09, 10F
→
01/12 11:11, , 11F
你的code反而跑得更慢, 而且又難看! 有很了不起嗎?
01/12 11:11, 11F
→
01/12 11:17, , 12F
我不認同AMI主管講話方式,不過TechJob焦點本來就是在求職
01/12 11:17, 12F
→
01/12 11:17, , 13F
你現在在這邊喊焦點是在程式寫法..不是白說的嗎...
01/12 11:17, 13F
焦點是藉技術問題來看雙方的心態 求職者不了解業界習慣 公司主管把自身經驗擴大解釋成最嚴謹的語法 ※ 編輯: deo2000 來自: 140.122.165.222 (01/12 11:25)
→
01/12 11:26, , 14F
所以一個是沒看過的寫法就先全盤否認,一個是用一些冷僻用法
01/12 11:26, 14F
→
01/12 11:26, , 15F
上來討拍(然後這寫法也沒比較好)...
01/12 11:26, 15F
推
01/12 11:38, , 16F
那主管應該很久沒面試了，很多公司喜歡出這樣的題目考人XD
01/12 11:38, 16F
推
01/12 11:41, , 17F
不過原PO也學到不用%取餘數的方法，大家開心就好啦XD
01/12 11:41, 17F
推
01/12 11:46, , 18F
要是我是主管，不用%取餘得到的分數會比原PO的寫法來的高
01/12 11:46, 18F
是阿,為了此事第一次認真地看組語
→
01/12 11:49, , 19F
不同CPU架構的compiler會有差異, 你覺得效能好的寫法在
01/12 11:49, 19F
→
01/12 11:49, , 20F
某些cpu上不見得試用, 而且現在的cpu有很多偷吃步的作法
01/12 11:49, 20F
→
01/12 11:50, , 21F
像是superscalar pipeline.. 所以我覺得你一直在爭論哪
01/12 11:50, 21F
→
01/12 11:50, , 22F
一種方式才是最佳解很沒意義,要看CPU架構採取不同的方式
01/12 11:50, 22F
→
01/12 11:51, , 23F
而且可讀性/軟體軟體架構我覺得才是日後發展的關鍵
01/12 11:51, 23F
→
01/12 11:51, , 24F
"適用", 筆誤
01/12 11:51, 24F
您說的沒錯，在Tech_Job版爭這種技術，格局實在太小了
推
01/12 11:52, , 25F
樓上也是正解 不保證快 保證難懂 根本沒價值
01/12 11:52, 25F
推
01/12 11:53, , 26F
而且光是你會用%來判斷奇偶數這點,就已經不是效能的保證
01/12 11:53, 26F
推
01/12 11:56, , 27F
樓上突破盲點了 說老實話我才被點醒 原PO懂了沒?
01/12 11:56, 27F
→
01/12 11:58, , 28F
原PO去查怎麼判斷奇偶數更快吧 效能可能差到百倍千倍
01/12 11:58, 28F
抱歉，以AT89S51為平台編出來的asm完全一樣 http://imgur.com/VIgWi
推
01/12 12:41, , 29F
那你的方法好在哪裡? ^_^ 再來 MOD的速度問題解決了?
01/12 12:41, 29F
※ 編輯: deo2000 來自: 140.122.165.222 (01/12 12:47) ※ 編輯: deo2000 來自: 140.122.165.222 (01/12 12:51)
推
01/12 13:17, , 30F
那是編譯器聰明，跟你沒有關係XD
01/12 13:17, 30F
推
01/12 13:19, , 31F
說難聽點，光用%做運算就會讓人質疑你有沒有寫過mcu
01/12 13:19, 31F
→
01/12 13:20, , 32F
你拿語法出來說嘴只會讓閱聽者覺得是在炫技
01/12 13:20, 32F
推
01/12 13:22, , 33F
如果你面試題目都做對再來跟主管討論語法
01/12 13:22, 33F
→
01/12 13:23, , 34F
才會讓人覺得你有點credit~~
01/12 13:23, 34F
推
01/12 13:25, , 35F
不想對剛畢業的人說重話，但是你的態度還真讓人不敢恭維
01/12 13:25, 35F
推
01/12 13:52, , 36F
會完全一樣是因為Keil C的compiler幫你做掉了
01/12 13:52, 36F
→
01/12 13:53, , 37F
可以參考instruction set的JNB指令
01/12 13:53, 37F
→
01/12 13:53, , 38F
01/12 13:53, 38F
→
01/12 13:54, , 39F
但不能保證每種cpu core的指令集都支援類似的指令
01/12 13:54, 39F
→
01/12 13:56, , 40F
像是x86, ARM, PowerPC, mips,每家都會有自己的應用
01/12 13:56, 40F
推
01/12 14:02, , 41F
有興趣可以去看看ARM的application note, 裡面有一些文
01/12 14:02, 41F
→
01/12 14:03, , 42F
件就是有特別說明對於ARM架構來說, 用除法方式來做計算
01/12 14:03, 42F
→
01/12 14:03, , 43F
的缺點, 當然如果你覺得現代的compiler技術很聰明,不需
01/12 14:03, 43F
→
01/12 14:04, , 44F
我們開發時格外小心~ 那我也沒話說, 鬼打牆到此為止 XD
01/12 14:04, 44F
→
01/12 14:08, , 45F
我只能說演算法/架構才是一切的基礎, coding style是可
01/12 14:08, 45F
→
01/12 14:09, , 46F
以方便後續開發人員參與討論或trace code的方式
01/12 14:09, 46F
→
01/12 14:10, , 47F
而且我想你既然都把asm秀出來做比較, 很明顯就是編譯器
01/12 14:10, 47F
→
01/12 14:11, , 48F
本來就會做一些最佳化的動作,那還不如寫得易懂有條理
01/12 14:11, 48F
→
01/12 14:12, , 49F
我想大家的重點是在這裡, 而不是硬要定你對語法的敏銳度
01/12 14:12, 49F
推
01/12 14:14, , 50F
現在的軟體開發不管是大型系統或是小型的SoC,整個架構都
01/12 14:14, 50F
→
01/12 14:15, , 51F
很複雜, 分工也很細,不是每個人對語法的進階技巧都熟悉
01/12 14:15, 51F
→
01/12 14:16, , 52F
否則也不會有一堆公司強調SW必遵守Coding Convention
01/12 14:16, 52F
→
01/13 07:51, , 53F
你先試試看optmiztion關掉，再看看後面會不會跑
01/13 07:51, 53F
噓
01/13 22:47, , 54F
難道我會return EFI_SUCCESS;也要拿來說嘴?????
01/13 22:47, 54F
→
01/13 23:31, , 55F
Keil跑得起來很了不起嗎? 萬一遇到別家的編譯器編不過時呢?
01/13 23:31, 55F
噓
01/14 00:02, , 56F
不要在"最佳化"上面打轉，AMI的考題就助教大人您自評應該
01/14 00:02, 56F
→
01/14 00:03, , 57F
應該能夠得幾分啊？
01/14 00:03, 57F
噓
01/14 07:50, , 58F
樓上大大 他不會用&1判斷奇偶數 談效能根本差很遠
01/14 07:50, 58F
推
01/14 16:52, , 59F
@@" 不就是看最後一位是啥就好了啊?
01/14 16:52, 59F
→
01/14 16:53, , 60F
還有一個方法是shift後看carry就好了
01/14 16:53, 60F
→
02/01 09:25, , 61F
結果那個主管要叫你在去嗎~~ ?
02/01 09:25, 61F
推
03/22 00:38, , 62F
()&& !()&& 事實上是兩個if, 不能拿if-else if做比較, asm
03/22 00:38, 62F
→
03/22 00:38, , 63F
一定會不一樣的
03/22 00:38, 63F
‣ 更多 deo2000 的文章
文章代碼(AID): #1GyC5A08 (Tech_Job)
討論串 (同標題文章)
完整討論串 (本文為第 5 之 7 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共7篇)
‣ 更多 deo2000 的文章
文章代碼(AID): #1GyC5A08 (Tech_Job)