Re: RES: [Dev-C++] Re: C and C++

[Per W. <pw...@ia...>]

One problem with bigger code is that just about all applications larger
than hello world is getting bigger than the processor cache. That,
together with multiple concurrently running programs, make us loose a lot
of the total processoer capacity in costly cache misses.

That is one situation where it is a bit easier to optimize in a C program
- a non-OO program makes it easier to place all costly functions close
together in a single file, letting them better fit in the cache.

If a cache line - the modularity of the CPU cache - is 32 byte, a single
char variable at an unlucky location will result in a cache waste of 31/32
or 97% When overriding a base class, you can't control where any new
member variables are placed in the object.

But then again - for 97% of all applications, it doesn't matter how
efficient the processor is used. They solves so small problems that it is
enough if they just get any processor time at all.

/Per W

On Wed, 23 Apr 2003, Daniel K. O. wrote:

>
>
>
> I think that a few KB shouldn't be a problem nowadays. If you want a small
> binary, you can UPX it, and pay the price of uncompressing the code
> everytime you run it. I personally don't mind if the .EXE is bigger, if it
> can run faster than a smaller one.
>
>
>
> Daniel K. O.
>
>
>
>
>  >  -----Mensagem original-----
>  >  De: dev...@li...
>  >  [mailto:dev...@li...]Em nome de Per
>  >  Westermark
>  >  Enviada em: quarta-feira, 23 de abril de 2003 19:04
>  >  Para: Samuel Keding
>  >  Cc: dev...@li...
>  >  Assunto: Re: [Dev-C++] Re: C and C++
>  >
>  >
>  >  We had a long discussion about memory layout and problem porting Fortran
>  >  routines efficiently to C++ some moths ago :-)
>  >
>  >  Well, language comparisons will always pop up in the list more or less
>  >  regularly.
>  >
>  >  One thing about size of binaries.
>  >
>  >  For a small binary, even a little extra results in a large proportional
>  >  difference.
>  >
>  >  Some few reasons why C++ applications gets larger:
>  >  - Mangled names results in larger debug information.
>  >  - More complex data structures in the header files results in
>  >  larger debug
>  >  info.
>  >  - Most OS have C-like API, so a lot of low-level C++ classes must in the
>  >  end call C function, while the C app sometimes could call the C function
>  >  directly.
>  >  - C++ compiled with RTTI adds a lot of extra book-keeping in the binary.
>  >  - Support for some combinations of multiple-inherritance
>  >  results in a lot
>  >  of extra code to type-cast between super- and sub-classes.
>  >  - Exception support, to correctly find all auto-declared objects to
>  >  destruct on the stack.
>  >  - Template code that results in code expansion, where the
>  >  application gets
>  >  several versions of similar code.
>  >
>  >  Yes, there are a number of reasons why a C++ application might
>  >  be smaller
>  >  too, such as good use of virtual methods to better reuse code
>  >  in abstract
>  >  base classes etc...
>  >
>  >  However, the most common reason for larger C++ binaries is that libc++
>  >  adds in a lot of extra goodies that quickly bloats small programs, but
>  >  makes large applications grow slower because of code reuse.
>  >
>  >  /Per W
>  >
>  >  On Wed, 23 Apr 2003, Samuel Keding wrote:
>  >
>  >  > Hey,
>  >  >
>  >  > A language doesn't equal religion. For those of you who can
>  >  only read C or C++
>  >  >
>  >  > bool isEqual = (language == religion)
>  >  >
>  >  > cout or printf isEqual
>  >  >
>  >  > On the console appears 0.
>  >  >
>  >  > It doesn't really matter a lot. C can be more effiecent at
>  >  times, and ease is a matter of opinion. Some problems are
>  >  easier to understand in the object oriented sense. In that
>  >  case, C++ will probably be easier. In any case a langauge is a
>  >  tool. If your welding you might want a welding torch. However,
>  >  you probably do not want to use a welding torch when drying the
>  >  clothes. You probably want to use a dryer for that. C, C++,
>  >  Java, Fortran, use them where it proves useful. Oh, one other
>  >  thing, Fortran is evil. Do not use it.
>  >  >
>  >  > :D
>  >  >
>  >  >
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>