Re^4: How to vectorize a subroutine--perhapse using PDL piddles or threads

Ok, you convinced me. You will probably find my code primitive--and to my defense I am still new to perl. I should also confess I am new to parallel computing. I am learning as I go along. I have yet to find a program that can bridge programs that take input files and create output files to other programs. I chose perl after considerable research because it was well designed for parsing quickly.

That being said, hacking together this program has been a tremendous effort for me--and I must admit, I had plenty of help from other forums. I figured that should anyone else want to perform similar task as I (in this case, graphing the potential energy of a water molecule as a function of bond length and bonding angle) would go through similar struggles, so I wanted to publish my work to get some recognition (and something to put on a resume) and make my final product freely available to others who want to perform similar tasks.
Since I do not know how to attach files, I will copy and past my subroutines as if they were part of the same program.

code removed
[download]

These subroutines are actually organized into a couple of files and modules, but this code (I changed a few things in the first subroutine so this would be true) should actually run if you have psi3 installed and a template file in the correct directory called "psi3water".

The most computational time is by far spent executing psi3--but there is not much I can do about that. It is doing some very complex calculations that are inevitably going to take considerable cpu time. When I read about threading and vectorization, I essentially thought they provided a way of executing as many independent tasks as the cpu could handle at once--thus providing a more efficient alternative to looping through these independent tasks.
I apologize for my ignorance.

Also,
Versatility has been a goal for this project. I wanted to keep my program versatile enough to be able to fill in a wide variety of input files for a wide variety of programs and extract a wide variety of data from the output file.

Comment on Re^4: How to vectorize a subroutine--perhapse using PDL piddles or threads Download Code

Replies are listed 'Best First'.
Re^5: How to vectorize a subroutine--perhapse using PDL piddles or threads by BrowserUk (Patriarch) on Sep 08, 2010 at 19:31 UTC
Okay. You might want to remove your code, because I do not think that there is much that we can do to help you. Beyond suggesting that you should use strict and -w, which would allow you to notice things like: `open (INPUTFILE, ">$inputfile"); ... close(INTPUTFILE);` [download] And that you should be using lexical file handles within your subroutines. Being IO-bound code, there is not a lot that could be done to speed this up. I assume from your explanation that most of the CPU bound stuff is going on inside the `psi3`, and that is outside your remit to tune. Previously, from your mention of PDL, I thought that you were doing the complex math. All that leaves is a little relatively simple, IO-bound code that will not benefit from threading or PDL. Probably your best bet would be to look at Parallel::ForkManager and see if that fits with you aspirations. It would allow you to start your processes, whilst managing how many run concurrently. If you think that module fits the bill, and you need help on how to use it, I'd suggest posting a new question with that in the title, as I have no experience of it. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. RIP an inspiration; A true Folk's Guy	[reply] [d/l] [select]
Re^6: How to vectorize a subroutine--perhapse using PDL piddles or threads by Feynman (Novice) on Sep 08, 2010 at 19:49 UTC
Thank you-I removed the code. On the contrary, you saved me weeks of research. Although there is less I can do to make my code run faster--it is great to know that so I can move on and look at other aspects! Also, that forking module seems very promising. I will absolutely look into it. Thanks again	[reply]