|
锁定老帖子 主题：ruby线程运行速度测试
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-11-03
P4 2.8 HT
1G RAM Ubuntu 6.06 Linux 2.6.15_27 SMP Ruby 1.8.3 难道是我RP高？ |
| 返回顶楼 | |
|
发表时间：2006-11-03
P4 2.8 HT
1G RAM Ubuntu 6.06 Linux 2.6.15_27 SMP Ruby 1.8.3 难道是我RP高？ |
| 返回顶楼 | |
|
发表时间：2006-11-03
complystill 写道 charon 写道 又一个非常小的疑问。
为什么每次执行，最后打印的那个count都是不一样的。 按理说，如果都是串行排队的，都应该是49999500000 难道ruby的green线程调度中，+=不是原子操作? 我用python写了一个类似的脚本，每次执行的最终结果都是一样的(当然每个线程的count结果每次都不一样),耗时大概是ruby脚本的1/7 += 在Java里也不是原子操作的, 需要对外部资源进行显式的synchronization. 不过既然是伪线程, 解释器去负责调度的, 按说应该比较容易实现成原子操作的. 不知道Ruby里有没有类似Java的 synchronized(obj) { ... } 这种机制? 有。obj.synchronize
require 'thread'
mutex = Mutex.new
cv = ConditionVariable.new
a = Thread.new {
mutex.synchronize {
puts "A: I have critical section, but will wait for cv"
cv.wait(mutex)
puts "A: I have critical section again! I rule!"
}
}
puts "(Later, back at the ranch...)"
b = Thread.new {
mutex.synchronize {
puts "B: Now I am critical, but am done with cv"
cv.signal
puts "B: I am still critical, finishing up"
}
}
a.join
b.join
|
| 返回顶楼 | |
|
发表时间：2006-11-04
complystill 写道 charon 写道 又一个非常小的疑问。
为什么每次执行，最后打印的那个count都是不一样的。 按理说，如果都是串行排队的，都应该是49999500000 难道ruby的green线程调度中，+=不是原子操作? 我用python写了一个类似的脚本，每次执行的最终结果都是一样的(当然每个线程的count结果每次都不一样),耗时大概是ruby脚本的1/7 += 在Java里也不是原子操作的, 需要对外部资源进行显式的synchronization. 不过既然是伪线程, 解释器去负责调度的, 按说应该比较容易实现成原子操作的. 不知道Ruby里有没有类似Java的 synchronized(obj) { ... } 这种机制? 像java那样的并发native thread，除非硬件/操作系统对+=实现了原子操作，否则靠VM自己是做不到原子操作这个份上。 像python那样的GIL来串行化线程的机制，有能力做到+=原子操作，而且看起来是做到了+=的原子操作。至少与当前ruby程序相应的python程序，总结果每次都是一样的。 而像ruby这样的green thread方式,应当更加容易做到啊。毕竟，做到这一点之后，对线程编程模型有很大的便利. |
| 返回顶楼 | |
|
发表时间：2006-11-05
aotianlong 写道 废话！！！
你用别的脚本语言比如PERL，PYTHON等来运行这样的计算，也需要那么长时间。 脚本怎么能跟C++相比，即使是JAVA也比不上C++更何况脚本了。 再说RUBY还不是用C写出来的？ 哎，不再同一个运行级别上的东西。 不是同一个运行级别上的代码就不能做比较吗？ 你这是什么意思？ 知道这种差距不是很容易根据项目需要选择不同的语言来开发吗？ |
| 返回顶楼 | |
|
发表时间：2006-11-05
charon 写道 complystill 写道 charon 写道 又一个非常小的疑问。
为什么每次执行，最后打印的那个count都是不一样的。 按理说，如果都是串行排队的，都应该是49999500000 难道ruby的green线程调度中，+=不是原子操作? 我用python写了一个类似的脚本，每次执行的最终结果都是一样的(当然每个线程的count结果每次都不一样),耗时大概是ruby脚本的1/7 += 在Java里也不是原子操作的, 需要对外部资源进行显式的synchronization. 不过既然是伪线程, 解释器去负责调度的, 按说应该比较容易实现成原子操作的. 不知道Ruby里有没有类似Java的 synchronized(obj) { ... } 这种机制? 像java那样的并发native thread，除非硬件/操作系统对+=实现了原子操作，否则靠VM自己是做不到原子操作这个份上。 像python那样的GIL来串行化线程的机制，有能力做到+=原子操作，而且看起来是做到了+=的原子操作。至少与当前ruby程序相应的python程序，总结果每次都是一样的。 而像ruby这样的green thread方式,应当更加容易做到啊。毕竟，做到这一点之后，对线程编程模型有很大的便利. 强迫线程的原子操作会巨大的降低系统整体性能 毕竟同步可不是个常见的工作 似乎OpenMP可以自动的同步 这个我并不太了解 |
| 返回顶楼 | |
|
发表时间：2006-11-05
whisper 写道 强迫线程的原子操作会巨大的降低系统整体性能 毕竟同步可不是个常见的工作 以机器码执行或做过机器码优化的可能有这个问题。但是对使用GIL的解释执行环境下处理这个原子操作应该非常容易，实现原子操作并不需要额外的同步。 |
| 返回顶楼 | |
|
发表时间：2006-11-05
aardvark 写道 有。obj.synchronize
require 'thread'
mutex = Mutex.new
cv = ConditionVariable.new
a = Thread.new {
mutex.synchronize {
puts "A: I have critical section, but will wait for cv"
cv.wait(mutex)
puts "A: I have critical section again! I rule!"
}
}
puts "(Later, back at the ranch...)"
b = Thread.new {
mutex.synchronize {
puts "B: Now I am critical, but am done with cv"
cv.signal
puts "B: I am still critical, finishing up"
}
}
a.join
b.join
不错不错, 用法和Java的一样精妙, 可以有效防止复杂代码块里忘记解锁而产生bug的倾向. 而且看样子是通过库扩展来实现的, 有了closure真的方便很多, Java还死抱着Anonymous Class来应付这种要求确实有点不尽人意. |
| 返回顶楼 | |
|
发表时间：2006-11-05
charon 写道 whisper 写道 强迫线程的原子操作会巨大的降低系统整体性能 毕竟同步可不是个常见的工作 以机器码执行或做过机器码优化的可能有这个问题。但是对使用GIL的解释执行环境下处理这个原子操作应该非常容易，实现原子操作并不需要额外的同步。 Nod, 只要选择在原子操作的边界来切换green thread上下文就可以了. |
| 返回顶楼 | |
