Re: question for C experts - strcpy vs memcpy (fwd)
Ted MacNEIL wrote: Thanks to all for your thoughts. And especially to David for doing a quick test for me. I honestly cannot believe that people are still 'optimising' CPU. Unless you call major chunks of CPU-intensive code, you are not going to find enough savings to buy a beer. An over-generalization that is definitely not true. Every language seems to have some features that can be expensive if mis-used. Whether this is critical or not in a particular program all depends on the application. If the application only burns several CPU seconds per month, then obviously this is a non issue, and spending extra time on optimization is wasted. (But since you never know when and where bad code may get cloned, to do something poorly when it takes minimal extra time to do it right is also un-professional). Does it ever make sense to tune CPU time for a program that only uses uses a few milliseconds of CPU? If it's part of an online transaction that executes several million times per day you better believe it! Especially if this is a transaction that runs during prime time when CPU resources are tight. Especially now that many have found that MVS is cheaper when you license it by the peak 4-hour CPU MSU average instead of by total hardware MSUs, failure to tune major CPU users that run during peak hours ends up costing additional real money on software licensing fees. Perhaps there are companies that never question whether additional hardware and/or higher software fees can be justified. Ours isn't one of them. For time-critical and cost-critical applications you would certainly want to start by eliminating unnecessary I/O and badly formulated queries. That will most likely reduce CPU significantly as well, but in many cases that may still not get the response time and costs down to where the end-user is satisfied, and you've got to dig deeper and eliminate other code inefficiencies. Faster processors may resolve response time issues for untuned applications, but on MVS the peak MSU's consumed by the application still drive software costs and are still relevant. I/O, even with today's faster hardware, is where you should be concentrating. Especially, on non-Mainframes. - Too busy driving to stop for gas! ... -- Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: question for C experts - strcpy vs memcpy (fwd)
I'll keep at it, CPU optimization, depending on size environment and where I draw the line with regards to payback. There are almost always tuning opportunities with regards to CPU. At my last client I would have been happy to get a few percent back since I knew we were not getting an upgrade and I was running flat out with a relatively high in ready. --- On Tue, 9/9/08, Ted MacNEIL [EMAIL PROTECTED] wrote: From: Ted MacNEIL [EMAIL PROTECTED] Subject: Re: question for C experts - strcpy vs memcpy (fwd) To: IBM-MAIN@BAMA.UA.EDU Date: Tuesday, September 9, 2008, 12:57 AM Thanks to all for your thoughts. And especially to David for doing a quick test for me. I honestly cannot believe that people are still 'optimising' CPU. Unless you call major chunks of CPU-intensive code, you are not going to find enough savings to buy a beer. I/O, even with today's faster hardware, is where you should be concentrating. Especially, on non-Mainframes. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: question for C experts - strcpy vs memcpy (fwd)
But Ted, there *are* good reasons to still optimize CPU, for example when your batch window is shrinking or your real-time volume is dramatically increasing. The programmers before us didn't all necessarily craft their code well, like a case I had recently where two 16Mb COBOL tables were being INITIALIZE'd for every record instead of once at start of program. IMHO, 20+ minutes of CPU time and many hours of elapsed time down to less than 0.5 of one minute of CPU time and 5 minutes of elapsed time (why oh why is MVCL so slow?) is a reasonable payback for the effort. I agree that I/O is the more common bottleneck, but it isn't always the only one. We are not wasting time to optimize our code whenever we see a problem, if the payback is large enough. It's a judgment call, to be sure, but that's what we're called on to provide to management -- our best judgment. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Monday, September 08, 2008 8:58 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: question for C experts - strcpy vs memcpy (fwd) Thanks to all for your thoughts. And especially to David for doing a quick test for me. I honestly cannot believe that people are still 'optimising' CPU. Unless you call major chunks of CPU-intensive code, you are not going to find enough savings to buy a beer. I/O, even with today's faster hardware, is where you should be concentrating. Especially, on non-Mainframes. This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: question for C experts - strcpy vs memcpy (fwd)
But Ted, there *are* good reasons to still optimize CPU I did say: Unless you call major chunks of CPU-intensive code, you are not going to find enough savings to buy a beer. You said the same thing. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: question for C experts - strcpy vs memcpy (fwd)
OK, I must have just skimmed over that part of your reply without activating any brain cells. Apologies for shooting from the lip. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Tuesday, September 09, 2008 10:51 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: question for C experts - strcpy vs memcpy (fwd) But Ted, there *are* good reasons to still optimize CPU I did say: Unless you call major chunks of CPU-intensive code, you are not going to find enough savings to buy a beer. You said the same thing. This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: question for C experts - strcpy vs memcpy (fwd)
On Mon, 8 Sep 2008, Mark Post wrote: On 9/8/2008 at 2:25 PM, in message [EMAIL PROTECTED], John McKown [EMAIL PROTECTED] wrote: -snip- Why don't I just look at the generated code? Because I don't have a C compiler for z/OS. I'm writing my code on Linux using GCC. You can see the generated code from gcc. Use the -save-temps flag and you'll get both the .s and .i files for the source module. Except that I don't understand Intel assembler. Mark Post -- Q: What do theoretical physicists drink beer from? A: An EIN stein. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: question for C experts - strcpy vs memcpy (fwd)
Thanks to all for your thoughts. And especially to David for doing a quick test for me. I apologize if I was too off-topic. This relates, vaguely, to my JCL parser. I was wondering whether to use memcpy or strcpy for LITERALS. For indeterminate length strings I do use strncpy and snprintf so that I don't get buffer overflows. -- Q: What do theoretical physicists drink beer from? A: An EIN stein. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: question for C experts - strcpy vs memcpy (fwd)
Thanks to all for your thoughts. And especially to David for doing a quick test for me. I honestly cannot believe that people are still 'optimising' CPU. Unless you call major chunks of CPU-intensive code, you are not going to find enough savings to buy a beer. I/O, even with today's faster hardware, is where you should be concentrating. Especially, on non-Mainframes. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: question for C experts - strcpy vs memcpy (fwd)
On Tue, 9 Sep 2008, Ted MacNEIL wrote: Thanks to all for your thoughts. And especially to David for doing a quick test for me. I honestly cannot believe that people are still 'optimising' CPU. Why not? I really cannot believe that a person's attitude would be who cares?. If I can do something in multiple ways, then I just consider it normal to want to do it as well as I can. Professional pride, I guess. I'll admit, in this application, it won't make a tinder's damn. But I still care. I don't want to be accused of being a bloated Windows programmer! grin. Unless you call major chunks of CPU-intensive code, you are not going to find enough savings to buy a beer. Diet coke for me, thanks! grin I/O, even with today's faster hardware, is where you should be concentrating. Especially, on non-Mainframes. - Too busy driving to stop for gas! Agreed. I/O is far more of a bottle neck than CPU. Especially went I'm mainly reading and writing. -- Q: What do theoretical physicists drink beer from? A: An EIN stein. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: question for C experts - strcpy vs memcpy (fwd)
That's what IBM started saying years ago, at the same time when they quit proving assembler instruction timing sheets :) It seems that Micro performance improvements aren't worth it anymore, at least if you listen to the people selling the hardware... David Logan Manager of Product Development, Pitney Bowes Business Insight http://centrus.com W: (720) 564-3056 C: (303) 818-8222 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Monday, September 08, 2008 18:58 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: question for C experts - strcpy vs memcpy (fwd) Thanks to all for your thoughts. And especially to David for doing a quick test for me. I honestly cannot believe that people are still 'optimising' CPU. Unless you call major chunks of CPU-intensive code, you are not going to find enough savings to buy a beer. I/O, even with today's faster hardware, is where you should be concentrating. Especially, on non-Mainframes. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
