Review your favorite Linux distribution.
Go Back > Forums > Non-*NIX Forums > Programming
User Name
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.


  Search this Thread
Old 05-29-2012, 07:05 PM   #61
Sergei Steshenko
Senior Member
Registered: May 2005
Posts: 4,481

Rep: Reputation: 454Reputation: 454Reputation: 454Reputation: 454Reputation: 454

Originally Posted by Nominal Animal View Post
My point for writing it is that I still believe this code yields the fastest execution time. I really would not mind being proven wrong.

Note that I just wrote this from scratch, it is not something I've yet tried to optimize any further. Other than working in groups of four indirect atoms, it is a very straightforward implementation, I think.

I'd be very interested to see an efficient C++ implementation we could compare to my SSE3 version above. If you need to tweak the problem to solve it better, please do; just remember that neighbor atom coordinates cannot be consecutively in memory, they have to be indirectly referenced, we need both distances and unit vectors, and the neighbors closer than the specified limit should be listed first in the result.

I still don't get your logic. Your example has nothing to do with "C" as defined by standard. I have no reason to believe that one, using 'gcc' suite, can't use exactly the same built-in SIMD primitives for C++.

C++ by itself does not imply overhead. With great (though not absolute) precision one can say that C++ is simply a superset of "C".

If you think "C" is faster, take the real differences between C++ and C99, i.e. use features that are present in C99, but not in C++, and using those features write C99 code which, you think, is better than similar code in C++.

Only that would be a good starting point to show performance advantages of C99 over C++.


Again, I do not like C++, I find it convoluted, tangled and illogical. But I'm trying to be objective.
Click here to see the post LQ members have rated as the most helpful post in this thread.
Old 05-29-2012, 09:30 PM   #62
LQ Guru
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 10,711
Blog Entries: 4

Rep: Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949Reputation: 3949
Generalizations are very difficult to make about the "relative execution time of" any program in any language, because the nature of the program, and of the specific source code that has been developed (said source code being, of course, very language-dependent) has much more influence than the language. Contrary to the popular opinions being expressed here, IMHO "C" is not used or not-used because it is "faster" ... it is used either because of history, or because of expressiveness.

The gcc compiler suite supports a half-dozen different languages using virtually the same "back end." Your source-code is translated to an intermediate format which is, from that point forward, language-independent.

A "C" program "assumes the co-existence of very little." In fact, say in the case of the Linux kernel, a program can be written which "assumes the co-existence of" absolutely nothing other than itself. The language permits the programmer to work at a somewhat-high level of abstraction or to "get down and dirty with the hardware," and everything in-between, and in fact you see the Linux kernel doing precisely that ... for over 21 radically-different hardware target platforms. When you need to do "that job," the C language is a tool designed to perform "that job."

Programming languages are "tools for the job." Nothing more or less. You have "an embarrassment of riches" to choose from, every one of them free.
Do not choose poorly.

"Why is C still out there?" Because very sound reasons for selecting it continue to exist ... and because literally hundreds of millions of lines of mission-critical software, still happily in service (including "Linux itself"), has been written using it ... and because it was and is "a wise choice" in those contexts. (It was, of course, specifically built to be so.)

Last edited by sundialsvcs; 05-29-2012 at 09:36 PM.
Old 05-29-2012, 11:35 PM   #63
Nominal Animal
Senior Member
Registered: Dec 2010
Location: Finland
Distribution: Xubuntu, CentOS, LFS
Posts: 1,723
Blog Entries: 3

Rep: Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948
Originally Posted by Sergei Steshenko View Post
C++ by itself does not imply overhead.
My experience indicates otherwise. In expert hands, the extra cost is just the dependency on (a specific version of) libstdc++. (Note that all programs, including C++ ones, depend on libc in Linux; either at link time or at run time. C++ binaries are larger, especially since every compiler version tends to produce a new non-downwards-compatible libstdc++.)

Before this thread, I believed it would be difficult to avoid using virtual methods and exceptions (which do have overhead); I thought the standard C++ library itself uses these features internally. I guess I was wrong, and the only unavoidable overhead is the standard C++ library dependency.

I'm not sure at which point g++ links in the standard C++ library, though. Both gcc -std=c99 and g++ -std=c++03 seem to produce the same binary when fed a C source file.

Originally Posted by Sergei Steshenko View Post
With great (though not absolute) precision one can say that C++ is simply a superset of "C".
Syntax yes, but languages no. They are governed by different standards. Although almost all of C code compiles as C++, it does not necessarily have the same semantics. Many are the same, but some important ones differ.

Consider Kahan summation algorithm:
double sum;   /* Accumulator */
double err;   /* Error accumulator */
double input; /* Value to add */
double tmp1, tmp2;

tmp1 = input - err;
tmp2 = sum + tmp1;
err = (tmp2 - sum) - tmp1;
sum = tmp2;
Traditionally, this code would have to be compiled without optimization, or some specific compiler settings, or the compiler would optimize it away yielding incorrect results.

In C99, the casting rules state that the compiler must retain the precision of a cast expression; optimization may not lead to a case where the cast expression is evaluated at a higher precision, even implicitly. In other words, given
tmp1 = (double)( input - err );
tmp2 = (double)( sum + tmp1 );
err = (double)( (double)( tmp2 - sum ) - tmp1 );
sum = tmp2;
a C99 compiler will happily optimize and still always produce correct code. As far as I can tell -- please correct me if I'm wrong --, the C++ standard only defines the results if the cast type differs: a C++ compiler may optimize the err factor completely out, yielding different results.

I think g++ does apply the same casting rules for C++. I believe Intel Compiler Collection does not, but I'm too lazy to check (I do not have it installed at home right now), so I might well be wrong.

In practice, I think most compilers nowadays apply optimization strategies that do not affect the result, but I do not see anything in the standards that would require them to do so, but which is sensible in practice because otherwise a lot of computational code would have to be compiled without optimizations to get the correct numerical results.

Originally Posted by Sergei Steshenko View Post
If you think "C" is faster
No. I am saying C++ is not faster.

Originally Posted by Sergei Steshenko View Post
Again, I do not like C++, I find it convoluted, tangled and illogical. But I'm trying to be objective.
I really do appreciate the discussion.


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off > Forums > Non-*NIX Forums > Programming

All times are GMT -5. The time now is 07:04 PM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration