tag:blogger.com,1999:blog-1527230864763214922.post8865080138867382685..comments2023-12-10T00:40:45.320-08:00Comments on Darryl Gove's Blog: The solution is multicoreDarrylhttp://www.blogger.com/profile/06979874258520423011noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-1527230864763214922.post-48814611290199617682010-08-07T11:50:31.726-07:002010-08-07T11:50:31.726-07:00@Brad. Scaling is an interesting problem. I've...@Brad. Scaling is an interesting problem. I've been meaning to write up a post about that.Darrylhttps://www.blogger.com/profile/06979874258520423011noreply@blogger.comtag:blogger.com,1999:blog-1527230864763214922.post-43995706730068259632010-08-07T11:49:06.574-07:002010-08-07T11:49:06.574-07:00@TerryD. Your OS looks interesting.
The point I&...@TerryD. Your OS looks interesting. <br /><br />The point I'm making is that multicore is not solely about developing a single application that takes advantage of all those cores. Often just having multiple cores makes your machine more productive.<br /><br />So rather than looking at these machines and complaining that they aren't a single core machine with twice the clock speed, we should be celebrating that our systems have become more responsive, and provide more throughput.Darrylhttps://www.blogger.com/profile/06979874258520423011noreply@blogger.comtag:blogger.com,1999:blog-1527230864763214922.post-56853585747520054962010-08-07T11:34:31.604-07:002010-08-07T11:34:31.604-07:00@xenoterracide. Yup. Plenty of experience with app...@xenoterracide. Yup. Plenty of experience with apps freezing etc. Chrome is a good example, MP works better for browsing because of the danger of tabs locking up. The main difference between MT and MP is that MT shares address space and MP doesn't. If the entire app locks up it's normally because of some locking issue. One thread should not cause another thread to stall unless there's some resource sharing going on there. That said, MP gives you robustness - so one tab doesn't take out the entire system.Darrylhttps://www.blogger.com/profile/06979874258520423011noreply@blogger.comtag:blogger.com,1999:blog-1527230864763214922.post-67238764719738910742010-07-06T14:11:46.522-07:002010-07-06T14:11:46.522-07:00Some problems are solved faster with multiple CPUs...Some problems are solved faster with multiple CPUs (or Cores). Password cracking for example. 16crack automatically detects the number of CPUs and is much faster when used with multiple cores. But it only scales so much. Similar problems have multiple starting points. If you have multiple CPUs it only makes sense to have one CPU start working on the problem here and another start there while ideally not duplicating any work. Unfortunately, not all problems are so easy to do this with. For the reporters example, the problem to solve is writing stories. So long as you have one reporter per story, you are OK. One does weather, the other obituaries and local news, the other international news and politics, etc. That seems multithreaded already. You don't need 10 guys all doing weather.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1527230864763214922.post-43059824315619297572010-07-06T12:06:36.653-07:002010-07-06T12:06:36.653-07:00RE: 'email' I don't know about you... ...RE: 'email' I don't know about you... but I've seen email client UI's become unresponsive while fetching lots of email. It reminds me of a web browser that becomes unresponsive due to a web page locking up the whole browser in a tab. You may not improve performance by going multiprocess, but you might improve responsiveness. Chrome is more responsive even when 1 tab is locked up because each tab has its own process. A mail client could improve much in the same way by fetching each mail account with its own process in the background.Anonymoushttps://www.blogger.com/profile/08185254298048097278noreply@blogger.comtag:blogger.com,1999:blog-1527230864763214922.post-22650893732183771642010-07-06T11:35:43.536-07:002010-07-06T11:35:43.536-07:00You're 10% number was pulled out of your ass. ...You're 10% number was pulled out of your ass. I'd guess you got it backward--90%. You ever actually tried to write for multicore? LoseThos is as good as it gets for multicofre -- complete control in your hands as master/slave configuration on one address space for everything. You're practically on bare metal, so you have no excuses and one address space is optimal as well.<br /><br />One problem is asymetric tasks, like prefetching and uncompressing files to save I/O for compiling. You have balancing issues and usually one task is an order of magnitude bigger -- tasks rarely are of similar size.<br /><br />With asymetric, you also have to worry about how many cores your users will have and they don't scale. A major thing that's holding me back is concerns for computers with only two cores when I have eight.<br /><br />Games and many things are real-time. The only option is degrading the quality for fewer cores. This is not always possible.<br /><br />If it's off-line, not real-time, like compiling, it's often but not always easy. I think such tasks are by far the exception, but maybe I imagine more people are interested in games.<br /><br />My operating system, LoseThos, http://www.losethos.com doesn't use graphics acceleration, so multicore games help a lot. If you have graphic acceleration, multicore matters a lot less for games because the CPU interacts serially with the GPU.Anonymousnoreply@blogger.com