※ 引述《gwliao (gwliao)》之铭言： : ※ 引述《micklin (Mick@Tucson)》之铭言： : : 当然我是假设不用元件或套件或函式库, 要自己写的时候。 : 这是算一次Cost/Fitness value的时间. : 假如能减少number of iterations的话, Total running time应该会减少. : 不知你是用别人的Solver还是自己写? : 假如是自己写话, 可以想想产生Next generation的方法. : 用Solver的话, 那要试试能调的参数. : : 其实我一开始想知道的就是, 能不能在写程式前就知道这样写有没有意义? : : 有专门的书或文章在探讨这一类的问题吗? : : 或者板友们有可以分享的心得吗? : 有啊, 读多一点书和写多一点程式. : 可以未写程式前, 先猜这有没有意义. 我觉得在演算法的层次上 在写之前本来就可以根据演算法本身的time/size complexity 来选择，如果是自己想的演算法 最好是自己推一下complexity (数学要够好XD) 这样才算是真正的设计演算法 必竟实作後牵涉的因素太多，倒推回去有的时候不是很准 而之前讨论的部份感觉起来其实满接近实作的范围 递回与回圈的比较，相信以看的懂组语的人来说根本就不是问题 而某些rule of thumb的确是可以在profile前提升效能 譬如针对cpu cache或是software pipeline的常识 或是阵列宣告等的小技巧 不过绝大多数的最佳化技巧，可能在某个平台上相当适合 而到另一个平台上就可能因为核心架构的不同而变成累赘 所以大部份的最佳化都会强烈建议等到profile後再进行 不然有可能是事倍功半 书的话比较少，毕竟演算法上的改良才是最有效的 实作上的技巧也会随硬体演进变化，没有太多不变的真理 在没有pipeline上的cpu玩software pipeline就一点用都没有 比起这个，良好的coding style更能够带来巨大的效益啊 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 61.62.22.95 ※ 编辑: invalid 来自: 61.62.22.95 (09/19 16:37)