※ 引述《invalid (everlasting)》之铭言： : ※ 引述《gwliao (gwliao)》之铭言： : : 这是算一次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更能够带来巨大的效益啊 资讯产业刚开始的时候 那时候也没有专门的程式设计师 程式大多是数学家在写的东西 现在渐渐变成显学 分工也越来越细 什麽职称都出来了 但是最终的目的还是开发效率 刚开始在硬体上讲究 後来把头脑动在人身上 每次软体商一个新名词新技术出来 大家总是追的如痴如醉 但是讲到最後还是 就像李开复讲的一样 核心应该注重於演算法 其他的部分可以用开发速度较快的语言编写 这样搭比较smart --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 61.218.161.130