From ramsuresh74 at hotmail.com Wed Oct 16 01:17:45 2002 From: ramsuresh74 at hotmail.com (suresh kumar) Date: Tue Mar 23 20:25:28 2004 Subject: [Okmicroarray] (no subject) Message-ID: An HTML attachment was scrubbed... URL: http://lists.onenet.net/pipermail/okmicroarray/attachments/20021016/b70fd931/attachment.htm From centolam at omrf.ouhsc.edu Thu Dec 12 01:23:01 2002 From: centolam at omrf.ouhsc.edu (Michael Centola) Date: Tue Mar 23 20:25:29 2004 Subject: [Okmicroarray] biocomputing Message-ID: <8C2BE264-0DA2-11D7-BB1E-003065F9500E@omrf.ouhsc.edu> My lab has been discussing micoarray biocomputing issues. These issues are likely to be relvant to other labs using the technology. We are discussing the options for enhancing the computing potential of the lab to shorten the time required for number crunching. I thought that a getting more input on these issues from the Oklahoma microarray community would be helpful. We just got our sever officially up and running (good job Alan!). BASE, a microarray database package, will be running on it soon. BASE will impose an order on our data that is now required for publication in many journals, will back-up the data, and in combination with the server, will provide facilitated access to all the data (both raw and reduced). The server can also be used to back up other data files and to share the burden of processing the data. In the future we hope to set up a parallel processing scheme to handle this. The current thread is regarding a simple question. Can the server be used to speed up analyses? The thread has been going around my lab for a while and should be read from the bottom up if you're interested. Mike Centola From Alan Shields Well the situation with the processors isn't so clear cut. The PIII in the server is a Xeon, which means that its L2 cache is much larger than even a PIV's, and the cache runs at a much higher speed than the PIV's. Because of this, mathematical calculations (which are predominantely cache-intensive) will be faster on the Xeon. Intel also changed the number of instructions per clock on the PIII vs the PIV, so comparing gigahertz between them is apples and oranges. In short, if this were just a PIII, then Matlab would definitely be slower. As it's not...well, the only way to tell would be to fire it up and see. Having said all this, we need to find out how much number crunching is slowing down the analysis. The best short-term solution is finding out if Matlab will let you cluster across operating systems. Alan From Yuhong Tang, I have been thinking about it. I agree with Nick's opinion that the processor is the bottle neck. However, I think if we put linux on the PC machine and run matlab in the linux environment, we could take advantages of the Linux system: 1) easy handling of batch files, 2) could become more automatic using Perl scripts. By putting the linux system and matlab on the server, we could access it through the web, this will be essential step for future users (collaborators). Moreover, it seems that Matlab already has an existing version for web usage. We need to study more to decide that which is better, the Matlab web version or the combo of Linux + Matlab + server+ cgi. Since I had no experience in multithreading, I have no comment on that aspect. Just some thoughts, hope it could help. Yuhong > From Nick Knowlton: > > Igor's new networking scheme can be very easily multithreaded. Almost > all > the calculations don't depend on the previous ones. Unless it is > multi-threaded I am curious as to how much faster the analysis will be. > The > server is only a PIII much slower at basic math than his PIV. Also, > code may need > to be optimized before we try to move it to the server. Just > increasing the speed > will give only nominal increases (just a few seconds faster). Original email: > Hi all, > > Igor has told me how cumbersome it is to perform his analyses on the > PC. Can we all work together to get Matlab for Linux up and running on > the server and then onto a distributed network to speed things up? I > think this is a high priority. Please respond to this email with your > thoughts on how we should proceed.