回复 #1 run_xiao2000 的帖子
觉得这样做得到的性能提升可能不会很大，毕竟词法分析是相对较快的。如果使用多线程，我觉得比较好的方法就是已经有很多人用的那种，把每个文件作为编译的单位，分别用不同的线程/机器编译。
编译器中最耗时间的部分应该是对中间语言的一遍遍的分析和优化。
分析不会改变程序，只是在收集信息，所以，如果需要多遍的分析，那么每一个完整的分析单元（例如针对过程内分析就是一个过程）相对于每一个分析遍，都可以独立出来作为一个线程。
优化会变换程序，于是，只能针对一个完整的优化单元来分成多个线程，在同一个单元中，各个优化遍只能顺序执行。 原帖由 henhao 于 2008-5-20 09:46 发表 http://linux.chinaunix.net/bbs/images/common/back.gif
fe不是瓶颈，这样搞会让程序变得很复杂，特别是错误处理，但对整个编译器的效率提高不大。
这个想法可能对效率提升不是很大，等我写完程序后时间测试一下。
不过我感觉并不会让错误处理复杂，错误处理只需和以前一样调用消耗Token的方法就好了啊。 建树和优化的过程应该还有提高的，虽然O(c*f(n))复杂度不会改变。但是系数的改变还是很可观的吧，多核的计算可能也在于此！ :em09: :em17: 昨天在tiny解析的功能上增加了线程和缓存的功能，在我机器上Run了几次，基本上起两个线程耗费的时间是一个线程的两倍左右。想想自己机器是单核的，让prolj兄帮忙在他双核机器上run了一下，降到1.5倍左右。
跟当初设想的差距还是挺大，难度线程的切换和同步这么耗时间？:em14: :em14: :em14:
我把程序传上来，双核机器的兄弟可以帮我Run起来试试看
make multi:两个线程运行
make single:单线程运行
[ 本帖最后由 run_xiao2000 于 2008-6-12 09:57 编辑 ] CPU Core2 Duo T5200，内存2g，运行结果
multi:
Create and consume 70 tokens,avarage produce time:2.314286,avarage consume time:1.828571
taken 1569 to parse the source code!
Create and consume 69 tokens,avarage produce time:2.347826,avarage consume time:1.898551
taken 1465 to parse the source code!
Create and consume 70 tokens,avarage produce time:2.371429,avarage consume time:1.828571
taken 1502 to parse the source code!
single:
Create and consume 68 tokens,avarage produce time:2.382353,avarage consume time:1.794118
taken 2611 to parse the source code!
Create and consume 69 tokens,avarage produce time:2.289855,avarage consume time:1.942029
taken 2925 to parse the source code!
Create and consume 69 tokens,avarage produce time:2.333333,avarage consume time:1.898551
taken 1823 to parse the source code! coldljy,thanks.