#天才の思考_高畑勳與宮崎駿 上市倒數7天
兒時的點點滴滴 │ 1991 │ 高畑勳導演
#研究狂高畑勳大顯神威
#用寫論文的精神製作出的電影
1986年4月20日，午後的莫斯科下著雨。莫斯科音樂學院的演奏廳裡，弗拉基米爾‧霍洛維茲的雙手放上琴鍵，接著垂下頭，舞台燈在他的側臉投下深邃的陰影。霍洛維茲有所思地停頓了一會兒，接著一揚眉，彈起了舒曼的《童年即景》。
六十年前，霍洛維茲在鞋襪裡夾藏了幾千美元，從此去國。彼時霍洛維茲的聲勢如日中天，甚至得到拉赫曼尼諾夫本人的首肯，宣布從此不再演奏第三號鋼琴協奏曲，因為有著俄羅斯「黃金之心與鋼鐵身軀」的霍洛維茲無疑是最好的詮釋者。
而六十年後終於重屢故土的巨匠，捨棄了過往的大曲目，選擇演奏的是《童年即景》，他的觸鍵依然雄渾沉穩，彷彿為童年遊樂場裡的小腳印覆上了六十年的歲月腳步，緩緩地歷數童騃。
與霍洛維茲相同，宮崎駿先生在業界中也有著「暴君」的名號。在企劃《兒時的點點滴滴》時，宮崎先生無論如何希望由高畑勳導演，在聯合了鈴木敏夫先生軟硬兼施，甚至登門「懇談」之下，好不容易才拗到了高畑先生出馬。而高畑先生不做則已，既然應承了導演，他就 #非得要把每個細節全都研究透徹不可。為了瞭解紅花的種植方式，他甚至飛去當地的觀光課請教，看在外人眼中不免都替他捏把冷汗：「這樣隨興的製作進度沒問題嗎？」
當然有問題。但當我們看到《兒時的點點滴滴》那每一個畫格都值得品味的細節，第一次吃鳳梨那生動的表情（無疑也經過高畑先生的嚴格考究），彷彿就像聽見了霍洛維茲蘊藏豐富的琴聲。兒時之所以美好，正因為即興揮灑的童騃，每次回想都能重新發現教人驚喜的細節。
（文／新經典L小編，每天都要看奧運接著追蕭邦大賽）
-
#每個人心中都有一部吉卜力 ✨
《天才的思考：高畑勳與宮崎駿》 鈴木敏夫 著 8月4日上市‼️
https://vocus.cc/article/60ffd8e9fd89780001bf6a23
非得要把每個細節全都研究透徹不可 在 [鉤沉] 從自由度看軟硬體的分界- 看板ask-why 的推薦與評價
現今電腦的問題,已經龐雜而難以全攬
許多人都在自己的領域鑽研著
同樣的問題不該只有一種解法
就好像我要交一篇簡報出去
你說用 Win OS 下寫得出來
我說用 Mac 寫得出來
大致上來說,創意類的軟體 Mac 較擅長
但我不能因為自己用 Mac 做的很棒
就大口說"Win OS 下做的'不對' 吧"
不夠好或不夠全面,會是比較好的回答
但'完全不對'就反而太小看別種可能性了
那如果同一個問題,軟體有它的角度,硬體也有它的角度呢?
那我就要問"自由度"了
舉例來說
我做一個車床,可以自由運動一公尺 (這的確是我的工作經驗,這樣一台六百萬^_^)
這一公尺就是硬體的自由度
直線馬達根本沒軌道能到達的地方,你就不能叫我做,比如運動至 1.1 公尺處..不行~
為了控制車床,我又寫一個軟體,能下的指令是 X=0 ~ 100 (公分)
這就是軟體的自由度,也是剛好一公尺
這時還看不出問題,因為它們重疊得很好
不過硬體和軟體都很複雜,分屬兩個不同部門在做
所以當老闆要求改設計至兩公尺系統時,問題就出來了
請問誰可以解決問題?
答案是都可以,當然最好用成本考量,且要協調好
比方說硬體部門可以加個齒輪把馬達運動量乘二
那麼 X=100 時就運動到兩公尺處;硬體部門可以說這問題都交給硬體就好
軟體部門也能解決'部份',只要把 X 的極限值放大到 200, recompile 程式即可
但無論如何如果硬體不先把行程加大
軟體放開限制讓 X 能設定 200,只是讓馬達燒掉而已
(如果沒做硬體保護,整台車床衝出去撞到是會壓死人的,像墓碑那麼重
我們那次差點壓死的是老闆,所以工程師被一直狗幹 XD)
由此可見,不從根本做一個了解,一直打轉在非關鍵的問題是不行的
硬體及軟體都有它的限制
而有時,它們能做的影響,其範圍有重疊
在此例中我把架構繪為 2 Layer
而比如網路通訊,則喜歡講七層協定的概念
(概念是七層,但不一定真的做七層出來)
;;
CPU 和 整台電腦,其實現在也有分層了
講幾個例子:
CPU 被重置(Reset),不代表電腦重開機
CPU 被重置只確定了它內部所有暫存器回到初始值
但只要整個 OS 有規劃好後續動作,它可以不是重開機
而這樣的概念還真的被 OS 使用了
我搞不懂幹麻設計出這種應用
也許當初不是這個目的,但可以用它迴避一些問題
比如上面提到的齒輪,它解決問題沒有修改軟體來得漂亮
但它還是解決了問題
就存取記憶體方面,我們知道 CPU 在腳位上傳出位址(Address)
位址能送達 RAM,就能存取資料
但能傳出位址的不只 CPU,比如 DMA 也可以
要講細節我們會把 BUS 也描述出來, CPU 連接至 BUS,BUS 連接 RAM
DMA 控制 BUS 時 CPU 會離線,我們稱 DMA 這時佔用 BUS
RAM 並不知在 BUS 另一端是什麼東西,只要 BUS 按規矩送訊號電位來,它就動作
一般在取用資料時, CPU 一次送出一個位址,取回一筆資料
如果有四顆切割好的 RAM 顆粒,那我是不是可以要求四顆 RAM 同時動作呢?
那就看 BUS 怎麼設計;如果 BUS 全部短路在一起就沒法子
如果 BUS 也可以切成四塊,各別動作,那四顆 RAM 就可以同時動作
(就好像用四個磁頭讀寫硬碟,可以各別同時讀取硬碟的不同部份;打不打架就看設計了)
CPU 是無法一次處理四個位址(或者精確的說,四個不連續的位址)
但切成四塊的 BUS 卻可以獨立運作 XD 而這也是 cache 原理之一
CPU 你算你的,下面的 cache 我抓我的;相關但不限制對方,分工且合作
因此我們看到讀寫記憶體這個問題,學硬體的人和學 OS 的人看到的根本就不一樣
有點類似前述機械車床軟體及硬體部門自由度不同的問題
通常我們會希望有人全懂,綜覽全局把問題直接解決
那是一個經典,成本又低,速度又快
在電腦來說,這常是 BIOS 的角色
"CPU" 明明就一顆,"電腦"卻同時存取四個位址在 cache
這種事何必讓寫軟體的工程師費心呢?
也許我哪天改一款更快的電腦,是同時存取16個位址啊~~
而其他方式不是不能解決
但如果自由度不夠,就永遠差了一點
而且討論的通常都不夠關鍵
比方說,CPU 真實模式無法取用 1M 以上記憶體
但 1M 以下沒問題吧?
學到哪裏學哪裏的話,1M 以下用真實模式能做些什麼事?
回顧前面這段
> 大致上來說,創意類的軟體 Mac 較擅長
> 但我不能因為自己用 Mac 做的很棒
> 就大口說"Win OS 下做的'不對' 吧"
> 不夠好或不夠全面,會是比較好的回答
> 但'完全不對'就反而太小看別種可能性了
其實自由度不夠,看事情就不夠全面
但你仍然可以就你擅長的部份去盡全力了解(我後面會再補一段)
所以到底是"非得解決這個問題不可"
或者是"這個問題也只是我學習的一部份"
會有不同的細節要談
-------------
就以最前面車床,軟硬體自由度來說
軟體的發揮空間還是很大
雖然硬體決定行程,沒放到兩公尺則軟體完全不可能放大
但是校正這一部份全都是靠軟體在做
X=0 時, 真實座標 X'=0
X=1 時, X' = 1.1
X=50 , X' = 52
X=100 , X' = 101
如上,可能是我們量測軟體指令及硬體實際運動發現的誤差
我們當然要把這誤差校正回來,不然也不必賣到六百萬
(我們當然是 10^-9m 等級的精度,定位時間也得是微秒級;就是 CNC 車床啦)
車床定期會用雷射做一次校正,校個幾百點,把誤差值儲存起來
下指令時改下預估值,點與點之間再用內插法去預估
麻煩事還是很多,都要交給軟體做
所以都還有學習的價值
這樣一套系統是交給一個團隊在開發的
板友上來問問題,是一個個體而已
所以我哪敢拿團隊的經驗壓下去說"你想得太簡單"咧?
我反而會回憶起來,當初我們也是從瞎子摸象開始
一點一滴受鼓勵,愈懂愈多,終於全盤掌握(謙虛的說,是'大概'掌握)
所以我一向看得很寬容.. :P
要從哪一個角度來切入,都可以~
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 60.251.197.63
其實我還是沒寫好這篇,嗯..
所以可能要老板友比較知道我在講什麼
記憶體存取的問題和我談的還有段距離
我在談的是上次'記憶體檢測'的問題
我舉車床從一公尺擴展成兩公尺的例子是說
光從軟體是解決不了問題的,因為硬體不幫你加長,你就'永遠'不可能做到
所以不從硬體思考的人,就是沒拿到關鍵;不管你寫軟體再怎麼檢討也辦不到
但是這樣你的學習有沒有價值呢?
有,還是很有價值;你就先承認你只能控制一半距離就好
但是在這一半距離之內的問題你先研究透徹
以後在更上面會有一個主管來協助整合的
因此你只能做一半,就好好的做那一半
而且在業界人家一個 TEAM 做好的事,我怎麼去苛責到一個人呢?
那我就願意只討論那一小半,那也可以啊
我的意思是這樣
因此實際是實際,學習是學習
如果不劃開一條線,而要'最實際的學習'的話
因為問的是別人已解決的問題
十之八九我會背答案給你,而且幾乎只有唯一解
完全扼殺想像空間不必討論
為什麼只有唯一解?因為業界要賺錢,殺進殺出好幾年後,已經沒太多選擇了
不這麼做想必有什麼缺點,所以被淘汰
這種唯一解和學習的脈胳不太一樣
好像我拿一隻雞問師傅:
要用什麼火候才煮得好吃
師傅直接說:這東西根本不用火,最好吃是冰鎮(我凹太兇了,但我需要一些描述*_*)
這樣是扼殺我的發問..
我寧可每個答案都聽一聽
因為我要的是比較,而我的想像目前還停在火候
這是我學習的脈胳;但等我卓然成家時
我想,我也會用冰鎮吧! (有一種滷味就叫冰鎮滷味 XD)
大概還是很難表達好 *_*
※ 編輯: HuangJC 來自: 221.120.69.23 (12/26 00:44)
... <看更多>