On Wed, Apr 7, 2010 at 8:26 AM, Charles Shubert <cshub...@mit.edu> wrote:
> I'm confused by the 2400% CPU usage claimed below. Does this imply that
> 24 cores of a multicore machine are running at 100%?
>
> I have not been able to get Jmol to run on more than one core of my Mac 8
> core machine. In looking at the source code for Jmol 11.8.not_too_long_ago
> there seems to be a spot in the script interpreter to launch multiple
> threads which could exploit a multicore machine, but seems to launch only
> one thread to run the script itself. The code for this
> version's interpreter doesn't seem thread safe at first blush, so it doesn't
> seem like it is possible to get more than 100% CPU usage there.
>
> So, my questions are:
>
> - Does Jmol 12 exploit Java multi-threading?
>
no
> - If so, is this multi-threading for "file loading only" or a side-effect
> of something in Java or the operating system?
> - Is there a way to exploit multi-threading in Jmol?
>
I'm sure there is. And if VMD is any example, the use of GPUs would vastly
increase performance. It would be a great project for someone to explore.
Since I know nothing about parallel processing, I'm not the one to take it
on.
Mostly the "multithreading" aspects of Jmol are not that. They are
independent threads that carry out totally independent, unrelated tasks.
Mostly this is not a help in terms of performance; mostly it is a headache!
>
> My Jmol app uses isosurface rendering for quaternary structure of
> proteins. Right now, seven of the cores on my machine are idle and one is
> very busy. It would be nice to be able to put the calculation of every
> chain's isosurface on a thread to take advantage of whatever multicore
> capacity a user's machine has.
>
Yes, surfaces would be the place where this could be very helpful. One
thread could be independently building the planes of data that are processed
by the Marching Cube algorithm. I recently set Jmol up so that it creates
isosurfaces "progressively" -- that is, it only reads as much of the file at
a time to create the small slice of data necessary for the moment. This
already has markedly increased performance because one never actually holds
an nX x nY x nZ block of data in memory at any time. The Marching Cube class
requests blocks of data from the VolumeFileReader class -- sounds perfect
for multithreading. It seems to me isosurfaces would be a place where those
processors could help -- at least one more. Maybe something to look into. If
it's not difficult to set up, I'm game.
Bob
>
> --Chuck
>
> --- Original Message -----
>
> *From:* Robert Hanson <hans...@stolaf.edu>
> *To:* jmol-users@lists.sourceforge.net
> *Sent:* Wednesday, April 07, 2010 8:10 AM
> *Subject:* Re: [Jmol-users] Jmol -- two major advances
>
> Wow, thanks, Rolf. I thought perhaps you could do that! Oh, so close!
>
> First,
>
> write PNG
>
> just sends the image to your clipboard as an actual system-dependent image
> since you didn't specify a file name. So it was trying to create that when
> the error occurred. I'm guessing that happened not because the file was so
> large but instead because the ribbon was so tiny. I'll see if I can
> reproduce that.
>
>
> JPG64
>
> should not be there at all.
>
> Bob
>
>
>
> On Wed, Apr 7, 2010 at 4:32 AM, Rolf Huehne <rhue...@fli-leibniz.de>wrote:
>
>> On 04/05/2010 06:50 PM, Robert Hanson wrote:
>> > Thanks, Peter. Yes, that's a killer. Definitely not ready to read
>> 16,000,000
>> > atoms! But I have added a new option that lets you load some smaller
>> number
>> > of biomolecule transformations. Looks like we'll have to let Rolf open
>> that
>> > one for us.... ;)
>> >
>> Using Jmol 12.0.RC4_dev rev 12773 I opened the full 1m4x biological unit
>> file with all atoms successfully. It took about 520 minutes CPU time and
>> 21 GB of memory. (Until the memory was filled the CPU usage raised up to
>> 2400%, then it stayed at 100% for several hours.)
>>
>> (When I tried this before the same amount of memory was used but Jmol
>> somehow got stuck and I never got anything rendered.)
>>
>> You can't really work interactively (unless you have a CPU that is at
>> least 600 times faster than a 1.6 GHz Itanium processor) because it
>> takes about one minute for a command to work on all atoms.
>> But at least you can work with script commands.
>>
>> When I tried to export an image with "write png" I got the following
>> error message:
>>
>> JPG64
>> java.lang.ArrayIndexOutOfBoundsException: -1
>> at org.jmol.g3d.Hermite3D.renderHermiteRibbon(Unknown Source)
>> at org.jmol.g3d.Graphics3D.drawHermite(Unknown Source)
>> at org.jmol.shapebio.BioShapeRenderer.renderHermiteRibbon(Unknown
>> Source)
>> at org.jmol.shapebio.CartoonRenderer.render1(Unknown Source)
>> at org.jmol.shapebio.CartoonRenderer.renderBioShape(Unknown Source)
>> at org.jmol.shapebio.BioShapeRenderer.render(Unknown Source)
>> at org.jmol.shape.ShapeRenderer.render(Unknown Source)
>> at org.jmol.viewer.RepaintManager.render1(Unknown Source)
>> at org.jmol.viewer.RepaintManager.render(Unknown Source)
>> at org.jmol.viewer.Viewer.render(Unknown Source)
>> at org.jmol.viewer.Viewer.getImage(Unknown Source)
>> at org.jmol.viewer.Viewer.getScreenImage(Unknown Source)
>> at org.jmol.viewer.Viewer.renderScreenImage(Unknown Source)
>> at org.jmol.viewer.Viewer.renderScreenImage(Unknown Source)
>> at org.openscience.jmol.app.jmolpanel.DisplayPanel.paint(Unknown
>> Source)
>> at javax.swing.JComponent.paintToOffscreen(JComponent.java:5124)
>> at
>>
>> javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:278)
>> at javax.swing.RepaintManager.paint(RepaintManager.java:1224)
>> at javax.swing.JComponent._paintImmediately(JComponent.java:5072)
>> at javax.swing.JComponent.paintImmediately(JComponent.java:4882)
>> at
>> javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:785)
>> at
>> javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:713)
>> at
>> javax.swing.RepaintManager.seqPaintDirtyRegions(RepaintManager.java:693)
>> at
>>
>> javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:125)
>> at
>> java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
>> at
>>
>> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
>> at
>>
>> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
>> at
>>
>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
>> at
>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
>> at
>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
>> rendering error?
>>
>> Regards,
>> Rolf
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Jmol-users mailing list
>> Jmol-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jmol-users
>>
>
>
>
> --
> Robert M. Hanson
> Professor of Chemistry
> St. Olaf College
> 1520 St. Olaf Ave.
> Northfield, MN 55057
> http://www.stolaf.edu/people/hansonr
> phone: 507-786-3107
>
>
> If nature does not answer first what we want,
> it is better to take what answer we get.
>
> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
>
> ------------------------------
>
> _______________________________________________
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
>
--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107
If nature does not answer first what we want,
it is better to take what answer we get.
-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users
