The D Programming Language
in [C++]
|
From: Walter Bright on 27 Nov 2006 08:34 Peter Dimov wrote: > On the other hand, if only complex is optimized because it's part of > the core language, pair<int, int> and point2<double> won't be > enregistered even when passed by value. So users of complex win, but > everyone else loses. They're not losing anything they already have. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Catalin Marinas on 27 Nov 2006 10:14 Walter Bright <walter(a)digitalmars-nospamm.com> wrote: > I haven't looked closely at Python implementations, but my extensive > experience with javascript is it being interpreted is not what makes it > slow. It's the dynamic typing. I hear a lot about the static vs dynamic > typing, and which is better, but I've seen few mentions of the fact that > dynamic typing runs slowly, and I could find no way to fix it. > > I've had the sneaky suspicion for some time that type inference will > produce many of the benefits of dynamic typing, but with the performance > of static typing. There is another approach which gives acceptable results for a dynamically typed language - just-in-time specialisation (like JIT compilation but it generates several blocks of code specialised on the type of variables). This way it eliminates the time spent for type look-up. See http://psyco.sourceforge.net/introduction.html for how to optimise Python code (it has limitations as well, but I find this idea pretty good). -- Catalin -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Francis Glassborow on 27 Nov 2006 10:23 In article <O-SdnfKYCcRfqffYnZ2dnUVZ_vednZ2d(a)comcast.com>, Walter Bright <walter(a)digitalmars-nospamm.com> writes > Like spoken languages influence culture, to an even greater extent > programming languages influence how we *think* about programming. Very true. It is very difficult to take someone who has learnt a procedural language and get them to write in Lisp, Haskell etc. with any degree of fluency. They continue to think procedurally and then do a 'translation' into the language of use. For example anyone who learns programming based on a C sibling language has great difficulty in dealing with loops in Haskell, they keep looking for a for-loop and reject recursion. Coming in the reverse direction we have the problem of the functional programmer who instinctively uses recursion for iteration in C++. A well rounded education should, IMO, expose the student to significantly different languages. There really is little educational advantage in learning French, German and Spanish, but a great deal in learning Arabic, Chinese and some dialect of Sign. In the same way, learning C, C++ and Java (in any order) is not mind stretching but learning C++, Lisp and Scheme is much more beneficial (of course it is also much harder and does not provide the instant gratification that modern culture seems to demand). We really do not like to have to change the way we think even if it is good for us. -- Francis Glassborow ACCU Author of 'You Can Do It!' and "You Can Program in C++" see http://www.spellen.org/youcandoit For project ideas and contributions: http://www.spellen.org/ youcandoit/projects [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Francis Glassborow on 27 Nov 2006 10:24 In article <4569c5cf(a)news.broadpark.no>, Bj�rn Roald <bjorn(a)4roald.org> writes > 1. > It is hard to find existing relevant libraries that could be accepted > for projects. They are mostly: > - not standardized And how is that different from Java, C# etc. > - not shipped with compiler Ditto > - not portable or ported to all needed platforms However languages like Java, C# etc use a VM to circumvent that problem and generally do not try to provide for embedded systems. Note that were CLI widely implemented the C++/CLI dialect of C++ would reap the same benefit. > - not well known and trusted Oh? Well I do not trust most of the libraries written for those other languages. Many of them are simply of inadequate quality for mission critical programming. Another issue is that languages like Python are not portable in time because the language does not maintain portability of legacy code. > - not part of a community repository like CPAN for Perl IIRC their is very little quality control for code available that way. Boost for C++ sets very high requirements. Perhaps we could do with a repository with lesser entry requirements. > > 2. > If relevant library exist for C++ it can often not be accepted in > projects for the following reasons: > > a) legal concerns related to license terms Really, and that is different for other languages? > b) platform compatibility See above > c) known cost ? What do you mean? > d) lack of relevant support How is that different for Java etc. > e) risk related to future directions, continuation, or cost Even worse for many of the languages you listed. One high price for C++ is the requirement for supporting legacy code. > f) lack of legal entity responsible for intellectual property issues You are joking aren't you? > g) dependency is not desirable On what? > h) dependency issues pushed on customer if project is a library ? explain > i) conflicting use of names or versions of 3'rd party libs And that is different for languages like Java? C++ provides good tools for avoiding such problems in the first place (namespaces) -- Francis Glassborow ACCU Author of 'You Can Do It!' and "You Can Program in C++" see http://www.spellen.org/youcandoit For project ideas and contributions: http://www.spellen.org/ youcandoit/projects [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: kwikius on 27 Nov 2006 12:29
Andrei Alexandrescu (See Website For Email) wrote: > James Kanze wrote: > > Walter Bright wrote: > > > >>Peter Dimov wrote: > >> > >>>Walter Bright wrote: > >>> > >>>>5) better code generation (like for complex, we can (and do) return them > >>>>in the FPU registers rather than like a struct) > > > > > >>>If you optimize the general case of struct { X x; Y y; }, where X and Y > >>>fit in a register, you get much better ROI. > > > > > >>The C++98 Standard defines many operations on complex as taking an > >>argument of type complex&. That means taking a pointer to it, which puts > >>the kibosh on enregistering complex. > > > > > > In a naive implementation. > > > > The C++98 Standard never forbids making the functions of complex > > inline, in which case, a compiler should be able to eliminate > > not only the call, but also taking the address, and so should be > > able to keep all of the values in registers. > > Yes, I wonder about the same. If (1) a function taking T& can be > inlined, and if (2) it doesn't use the address of its parameter, > couldn't that code be optimized to put the thing in register(s)? I mean, > once you inline the function, any and all of the implemented > optimization spring to life. Unaliasing the function's parmeter with its > name is a "simple matter of unaliasing". :o) Below is some code with abridged assembler output following, showing relative performance of a UDT wrapping a double versus a raw double. compiled using VC*.0 with full link time optimisation. All the UDT operators use const ref arguments FWIW. In general functions don't seem to be the problem, rather UDT literals and using UDTs as loop counters. regards Andy Little //-------------------- (includes not shown) /* f1() and f1a() use the UDT, while f2() is the same expression with doubles. The code in f1() is inferior because of the UDT constant "gas_constant::R". If the constant is changed to an inline function as in f1a() the code is identical to the double version. (The pow<3> function was removed as it unfavourably favours the UDT FWIW) The UDT source is available at http://sourceforge.net/projects/quan */ void f1() { using quan::gas_constant; using quan::pow; using quan::temperature; using quan::pressure; using quan::length; using quan::volume; using quan::substance; double const & pi = quan::constant::pi; temperature::K T(310); pressure::Pa P(1.01325e5); length::m r(0.5e-6); volume::m3 V = 4.0 / 3.0 * pi * r * r * r;//pow<3>(r); substance::mol subst = P * V /(gas_constant::R * T); std::cout << subst << '\n'; } //An inline function can be better optimised by VC8 // than a constant defined in a cpp file inline quan::gas_constant::R_type gas_constant_f() { return quan::gas_constant::R_type(8.3145); } void f1a() { //using quan::gas_constant; using quan::pow; using quan::temperature; using quan::pressure; using quan::length; using quan::volume; using quan::substance; double const & pi = quan::constant::pi; temperature::K T(310); pressure::Pa P(1.01325e5); length::m r(0.5e-6); volume::m3 V = 4.0 / 3.0 * pi * r * r * r;//pow<3>(r); substance::mol subst = P * V /(gas_constant_f() * T); std::cout << subst << '\n'; } double const gas_constant_R(8.3145); void f2() { double const & pi = quan::constant::pi; double T(310); double P(1.01325e5); double r(0.5e-6); double V = 4.0 / 3.0 * pi * r * r * r// quan::pow<3>(r); double subst = P * V /(gas_constant_R * T); std::cout << subst << '\n'; } int main() { f1(); f1a(); f2(); } PUBLIC _main ; Function compile flags: /Ogtpy _TEXT SEGMENT _main PROC ; 108 : { push ebp mov ebp, esp and esp, -64 ; ffffffc0H ; 109 : f1(); fld QWORD PTR ?R@?$gas_constant_@N(a)quan@@2V?$ fixed_quantity@U?$unit@U?$abstract_quantity@U?$ dimension@U?$rational@$01$00(a)meta@quan@@U?$rational@ $0?1$00(a)23@U?$rational@$00$00(a)23@U?$rational@$0?0$00(a)23@U?$ rational@$0A@$00(a)23@U623(a)U723@@meta(a)quan@@Uvoid_(a)mpl@boost@@@ meta(a)quan@@U?$conversion_factor@U?$rational@$0A@$00(a)meta@quan@ @U?$rational@$00$00(a)23@U?$int_@$0A@@mpl(a)boost@@@23@@meta(a)quan@@N@2@B sub esp, 8 fmul QWORD PTR __real(a)4073600000000000 fdivr QWORD PTR __real(a)3d2dddd60ebd113c fstp QWORD PTR [esp] //........output.................. call ??6?$basic_ostream(a)DU?$char_traits@D(a)std@@@std@@QAEAAV01@N@Z ; std::basic_ostream<char,std::char_traits<char> >::operator<< <..output removed.> ; 110 : f1a(); fld QWORD PTR __real(a)3c77bb26c4c3e092 add esp, 4 fstp QWORD PTR [esp] //........output.................. call ??6?$basic_ostream(a)DU?$char_traits@D(a)std@@@std@@QAEAAV01@N@Z ; std::basic_ostream<char,std::char_traits<char> >::operator<< <... output removed...> ; 111 : f2(); fld QWORD PTR __real(a)3c77bb26c4c3e092 add esp, 4 fstp QWORD PTR [esp] //........output.................. call ??6?$basic_ostream(a)DU?$char_traits@D(a)std@@@std@@QAEAAV01@N@Z ; std::basic_ostream<char,std::char_traits<char> >::operator<< <...output removed...> ; 112 : } xor eax, eax mov esp, ebp pop ebp ret 0 _main ENDP _TEXT ENDS -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |