dev-cpp-users Mailing List for Dev-C++

You do realise that a reference is just a slightly modified pointer, with
required initialization and without any pointer manipulation allowed.

While you could do:
  const int &ref =3D 7;
the majority of code using references does:
  int var =3D 7;
  const int &ref =3D var;

Since 'const int &ref' allows for aliasing, i.e. that you have other
access methods to change the value that the reference points to, it is
hard - and often impossible - for the compiler to consider optimization
from a reference.

Since a reference - like a pointer - is an indirect access method, they
are not optimal for object access, unless you do a lot of localized
accesses using the same reference, in which case the compiler may cache
the reference in a register and thereby getting the same access times as
for a variable with a fixed address. Pointers and references are
at their best when you have a large object that you don't want to send as
a value, i.e. instead of a function taking a large struct as parameter, it
can take a reference to that struct.

However, that reference is - internally to the machine - identical to a
pointer, and when the compiler tries to access anything through the
reference, it have to do an indirection.

A reference isn't sometihng of zero size that doesn't exist. Except for
rare cases when the compiler is 100% sure about what it points to, the
reference have the same size - and will generate identical code - as a
pointer.

The whole id=E9a with a pointer or a reference is to either allow a variabl=
e
to point at different entities of something (such as when a constructor or
function takes a reference without knowing at compile time what it will be
initialized to) or when you have an object too large to send as a
parameter.

In both these cases, it is impossible for the compiler to optimize away
the address value stored by the reference, since that would either make
the constructor or function only supporting a hardcoded parameter, or
would in the second case force the large object to be sent on the stack
instead of just the address of the object.

So:
  const int &ref =3D 7;
would normally consume (sizeof(void*) + sizeof(int))




Don't know about writing of about data files. I think I mentioned map
files for looking at sizes of generated functions. But then again, the
size of the emitted code has very little correlation with the execution
speed.

About inlining - such as you get with
  #define MAX 7
or
  const int MAX =3D 7;
- are of course an advantage.

If the compiler generates code
  movl $7,%edx
instead of
  movl _MAX,%edx
there is no need for an extra memory reference, since in the first
alternative, the op-code already contained the value 7, while in the
second alternative, the processor must first parse the op-code, then check
it's data cache and/or issue a data read, and finally perform the move,
i.e. assigning a value to the eax 32-bit register.

/Per W

On Sun, 1 Jun 2003, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: Per Westermark [mailto:pw...@ia...]
> > Sent: Saturday, May 31, 2003 6:52 PM
> > To: Ioannis Vranos
> > Cc: 'Dev-C++ Mailing List'
> > Subject: RE: [Dev-C++] #DEFINE versus cont variables in array
> > inicializations
> >
> >
> > I don't know why gcc doesn't optimize a 'const int &var =3D
> > <value>' when
> > referenced.
>
>
> I was speaking compiler indepedently. You had said that const references
> occupy space while only const variables can be "inlined", and then you
> confused me with maps, data files and L1/L@ caches. :) I do not care what
> the current version of GCC does on this matter, the next version may beha=
ve
> differently or the previous versions or even ports of the same version on
> different machines.
>
> For built in array sizes only const variables and #define can do the job.=
 In
> general when I want to define a constant I use a const variable, but if I
> were space concerned I would use a const reference since references do no=
t
> have an address and in theory are more easy to be optimised out than obje=
cts
> (the same thing that happens when we pass const references to functions
> instead of object copies).
>
>
>
>
> > The only thing I could guess is that they never thought
> > it useful to optimize the use of the above declaration, since the
> > most common use for a const reference is something like:
> >
> > int var =3D 12;
> >
> > void func(const int& ref) {
> >     // do something
> > }
> >
> > int main() {
> >     func(var);
> > }
> >
> > In this case, the compiler doesn't know that func() is only
> > called with
> > var as parameter, i.e. with a constant value, so it can't optimize.
>
>
> Yes, but var is "inlined". On the other hand calling func(7), a temporary=
 is
> created.
>
>
>
> > If you think about it, what extra results are you expecting from the
> > following declaration? It is basically an unchangeable pointer to an
> > unchangeable value. But what improvements should it give to
> > your program?
> >
> > const int &var =3D 12;
>
>
> I consider that the compiler could more easily inline it than const int
> var=3D12; But anyway in real world programs for PCs, whether it will inli=
ne it
> or not, it doesn't matter.
>
> I disagree(d) with you that a const variable can be inlined while a const
> reference cannot. Theoretically both can be inlined, system-indepedently
> speaking.
>
>
>
>
>
> Ioannis Vranos
>
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL 1: http://run.to/noicys
> * Alternative URL 2: http://www.noicys.cjb.net
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> 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
>

> -----Original Message-----
> From: dev...@li... 
> [mailto:dev...@li...] On Behalf 
> Of Smurf, Papa
> Sent: Saturday, May 31, 2003 11:01 PM
> To: Scott Simontis SIMONTIS; dev...@li...
> Subject: RE: [Dev-C++] DirectX
> 
> 
> I didn't know that DevCPP can handle .NET.


It can't. .NET is an entirely object oriented api with a virtual machine
(with its own assembly!).





Ioannis Vranos
 
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

Entirely off topic but... :)


http://www.themexp.org/



It's the Longhorn visual style. :)




Ioannis Vranos
 
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net



-----Original Message-----
From: Smurf, Papa [mailto:smu...@xs...] 
Sent: Saturday, May 31, 2003 3:15 PM
To: Ioannis Vranos; dev...@li...
Subject: RE: [Dev-C++] Remove me from all mailing list!


Were did  you get the xp skin you are using?
-----Original Message-----
From: dev...@li...
[mailto:dev...@li...]On Behalf Of Ioannis
Vranos
Sent: zaterdag 31 mei 2003 7:40
To: dev...@li...
Subject: RE: [Dev-C++] Remove me from all mailing list!


Check this:

http://www23.brinkster.com/noicys/devcpp/ub.htm




Ioannis Vranos

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net 

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of
Scr...@ao...
Sent: Saturday, May 31, 2003 7:12 AM
To: dev...@li...
Subject: [Dev-C++] Remove me from all mailing list!



Please remove me from all mailing list!

E Mail: Scr...@ao...

Best Regards. ~Rodney Working~ 

> -----Original Message-----
> From: Per Westermark [mailto:pw...@ia...]=20
> Sent: Saturday, May 31, 2003 6:52 PM
> To: Ioannis Vranos
> Cc: 'Dev-C++ Mailing List'
> Subject: RE: [Dev-C++] #DEFINE versus cont variables in array=20
> inicializations
>=20
>=20
> I don't know why gcc doesn't optimize a 'const int &var =3D=20
> <value>' when
> referenced.


I was speaking compiler indepedently. You had said that const references
occupy space while only const variables can be "inlined", and then you
confused me with maps, data files and L1/L@ caches. :) I do not care =
what
the current version of GCC does on this matter, the next version may =
behave
differently or the previous versions or even ports of the same version =
on
different machines.

For built in array sizes only const variables and #define can do the =
job. In
general when I want to define a constant I use a const variable, but if =
I
were space concerned I would use a const reference since references do =
not
have an address and in theory are more easy to be optimised out than =
objects
(the same thing that happens when we pass const references to functions
instead of object copies).




> The only thing I could guess is that they never thought
> it useful to optimize the use of the above declaration, since the
> most common use for a const reference is something like:
>=20
> int var =3D 12;
>=20
> void func(const int& ref) {
>     // do something
> }
>=20
> int main() {
>     func(var);
> }
>=20
> In this case, the compiler doesn't know that func() is only=20
> called with
> var as parameter, i.e. with a constant value, so it can't optimize.


Yes, but var is "inlined". On the other hand calling func(7), a =
temporary is
created.



> If you think about it, what extra results are you expecting from the
> following declaration? It is basically an unchangeable pointer to an
> unchangeable value. But what improvements should it give to=20
> your program?
>=20
> const int &var =3D 12;


I consider that the compiler could more easily inline it than const int
var=3D12; But anyway in real world programs for PCs, whether it will =
inline it
or not, it doesn't matter.

I disagree(d) with you that a const variable can be inlined while a =
const
reference cannot. Theoretically both can be inlined, system-indepedently
speaking.





Ioannis Vranos
=20
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

I have the .NET framework already installed. I'm using the Win2k3 trial.

So what do I have to do now? Only way I see is calling .NET COMponents from
C,C++.

-----Original Message-----
From: Scott Simontis SIMONTIS [mailto:age...@co...]
Sent: zaterdag 31 mei 2003 22:15
To: Smurf, Papa
Subject: Re: RE: [Dev-C++] DirectX


To do it, you go to www.msdn.com. Then you get the .Net framework.



----- Original Message -----
From: "Smurf, Papa" <smu...@xs...>
Date: Saturday, May 31, 2003 4:00 pm
Subject: RE: [Dev-C++] DirectX

> I didn't know that DevCPP can handle .NET.
>
> How does it work? I have my doubts of interoperating with .NET
> from DevCPP.
>
>
> -----Original Message-----
> From: dev...@li...
> [dev...@li...]On Behalf Of Scott
> Simontis SIMONTIS
> Sent: zaterdag 31 mei 2003 20:40
> To: dev...@li...
> Subject: [Dev-C++] DirectX
>
>
> Two Questions on DirectX.
> 1. Is the syntax for the Dev-C++ DirectX the same as normal?
> 2. If I install the .NET compiler instead of mingw, will I be able
> to
> work with the version of DirectX not optimized for Dev?
> Thanks,
> Scott
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> 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
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> 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
>

Juliano,

if you want a library to do so, try jpeglib

For more information about the format try
JPEG-FAQ
The independent JPEG group web page http://www.ijg.org/=20
The JPEG Comitte site (www.jpeg.org).

Teosoft.

>   Does anyone know where I can find information - any webs=
ite - on=20
> reading/writing JPEG files?
>
>   Thanks for any help.
>   Juliano

---Publicidad-----------------------------------------------=
---------
=DAnete a los miles de sin pareja en Meetic... =A1te vas a e=
namorar!
http://www.iespana.es/_reloc/email.meetic

I didn't know that DevCPP can handle .NET.

How does it work? I have my doubts of interoperating with .NET from DevCPP.


-----Original Message-----
From: dev...@li...
[mailto:dev...@li...]On Behalf Of Scott
Simontis SIMONTIS
Sent: zaterdag 31 mei 2003 20:40
To: dev...@li...
Subject: [Dev-C++] DirectX


Two Questions on DirectX.
1. Is the syntax for the Dev-C++ DirectX the same as normal?
2. If I install the .NET compiler instead of mingw, will I be able to 
work with the version of DirectX not optimized for Dev?
Thanks,
Scott



-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
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

Two Questions on DirectX.
1. Is the syntax for the Dev-C++ DirectX the same as normal?
2. If I install the .NET compiler instead of mingw, will I be able to 
work with the version of DirectX not optimized for Dev?
Thanks,
Scott

Juliano wrote on:Sat, 31 May 2003 01:38:47


 > Does anyone know where I can find information - any website - on=20
 >reading/writing JPEG files?

You can find ANY format reference @ wotsit.org


Marcel Louwers

<P>Hi!</P>
<P>Please, I would like to know how I can install dev packs in the Dev-Cpp
4. </P>
<P>Thanks,</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Raquel Pillat.</P>
<br />
<br />
________________________________________________
<br />
Este E-mail foi enviado Usando o Software DETECMAIL 1.0
<br />

MessageWere did  you get the xp skin you are using?
  -----Original Message-----
  From: dev...@li...
[mailto:dev...@li...]On Behalf Of Ioannis
Vranos
  Sent: zaterdag 31 mei 2003 7:40
  To: dev...@li...
  Subject: RE: [Dev-C++] Remove me from all mailing list!


  Check this:

  http://www23.brinkster.com/noicys/devcpp/ub.htm




  Ioannis Vranos

  * Programming pages: http://www.noicys.freeurl.com
  * Alternative URL 1: http://run.to/noicys
  * Alternative URL 2: http://www.noicys.cjb.net


    -----Original Message-----
    From: dev...@li...
[mailto:dev...@li...] On Behalf Of
Scr...@ao...
    Sent: Saturday, May 31, 2003 7:12 AM
    To: dev...@li...
    Subject: [Dev-C++] Remove me from all mailing list!



    Please remove me from all mailing list!

    E Mail: Scr...@ao...

    Best Regards. ~Rodney Working~

I don't know why gcc doesn't optimize a 'const int &var = <value>' when
referenced. The only thing I could guess is that they never thought
it useful to optimize the use of the above declaration, since the
most common use for a const reference is something like:

int var = 12;

void func(const int& ref) {
    // do something
}

int main() {
    func(var);
}

In this case, the compiler doesn't know that func() is only called with
var as parameter, i.e. with a constant value, so it can't optimize.

If you think about it, what extra results are you expecting from the
following declaration? It is basically an unchangeable pointer to an
unchangeable value. But what improvements should it give to your program?

const int &var = 12;

/Per W

On Sat, 31 May 2003, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: dev...@li...
> > [mailto:dev...@li...] On Behalf
> > Of Ioannis Vranos
> > Sent: Saturday, May 31, 2003 3:22 AM
> > To: Dev-C++ Mailing List
> > Subject: RE: [Dev-C++] #DEFINE versus cont variables in array
> > inicializations
> >
> >
> > I just checked it and it seems you are right. Don't know why yet.
> >
> >
> > However does the above style make the compiler to give it an
> > address? That
> > would be very strange. I shall check the standard now.
>
>
> TC++PL on pages 199,200 says that const has by default internal linkage. So
> the definition must be accomanied by the keyword extern too.
>
>
> So my code becomes:
>
>
> temp2.cpp:
>
> extern const int x=17;
>
>
> temp.cpp:
>
> #include <iostream>
>
>
> extern const int x;
>
>
> int main()
> {
>  const unsigned char *p=reinterpret_cast<const unsigned char *>(&x);
>
>
>  // Shows x representation in memory in byte values
>  // including padding bits
>  for(unsigned long i=0; i<sizeof(x); ++i)
>    std::cout<<static_cast<short>(p[i])<<" ";
>
>
> }
>
>
> C:\c>g++ temp.cpp temp2.cpp -o temp
>
> C:\c>temp
> 17 0 0 0
> C:\c>
>
>
> So in this case the compiler can know if the const object or *reference* is
> accessed in another translation unit.
>
>
>
> However why a compiler would "inline" const int x=7; and  would not be able
> to "inline" const int &x=7; isn't clear and would be nice if you explained
> it to us. And please do not involve L1/L2 caches, we are talking about
> inline substitution here. And my CPU may have no cache.
>
>
>
>
> Ioannis Vranos
>
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL 1: http://run.to/noicys
> * Alternative URL 2: http://www.noicys.cjb.net
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> 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
>

What we could see was that the original loop didn't allow inlining. By
just touching it enough to get inlining, we get a 50% speed increase (for
all but the memory-choked Celeron machine that used an older compiler).

We didn't have to do much, it was just a 2-minute change to get gcc to fit
the loop within available registers.

One nice thing about newer x86 processors is that if the array elements is
sized 2^x, the processor can use it's built-in barrel-shifter and do a
constant-time multiply when loading values from the array, i.e. src[i],
where it i in this case gets automatically multiplied by 2 at each access.
Thank you Intel. This allows the removal of a src++ without any cost. But
it doesn't always work - depending on the array-element size. Besides,
with multiple integer pipes the processor might squeeze in the src++
operation somewhere anyway.

The previous post was without -fexpensive-optimizations.

The following is tests with your modified loop:
Compiler: gcc 3.2
Optimization: -O3, -march=pentium3, -fexpensive-optimizations.
Machine1 = Pentium II, 2*400MHz, PC100
Machine3 = AMD XP2600+, PC3200 CL2.5
Timing: In seconds wall-time.
CPU load: >= 98%

1 billion loops, 7 columns
Machine:  1     3
Loop 1    198   31
Loop 2    234   29
Loop 3    100   12
Loop 3b   157   28
Loop 4    199   38

100 milion loops, 200 columns
Machine:   1      3
Loop 1        87
Loop 2        93
Loop 3        65
Loop 3a       80
Loop 4        73
'
I must say that I am puzzles why I couldn't get similar results as your
PIII processor. However, with the expensive-opt on, the inlined code in
main() is very, very hard to read :-( while giving just about the same
times as from my previous mail without the flag.

However, it looks like the compiler fucked up to align the 3A loop when it
inlined it. The following is a test with -O2, i.e. no inlining - the
non-inlined methods do align the loop.

100 million loops, 200 columns
Machine:   3
Loop 1    412
Loop 2    425
Loop 3    380
Loop 3b   360
Loop 4    370

In this case I got an improvement from Loop 3b. However, let the numbers
talk. I would definitely recomment inlining...

/Per W

On Sat, 31 May 2003, Daniel K. O. wrote:

>
>
>  >  It is nice that you can laugh at my code. However, I DID benchmark
>  >  the code before writing the previous mail...
>
>
> Well, I didn't say that, sorry if you got pissed with what I said. I didn't
> said that optimizing coded is useless.
> You really did optimize some stuffs, and I didn't say that everything would
> be automagically optimized; I pointed out that there are some minor details
> that some people still think that can be "optimized" by just writing the
> same commands in a different way (not necessarily a different
> algorithm/order).
>
> I modified your code a little, to just show what I really said:
>
>
> ---
> #include <time.h>
> #include <stdio.h>
>
> #define MAX 100000000 // your code have an extra zero, I took it out so we
> won't measure the calling code, but the loop
>
>
> typedef unsigned __int64 DWORD64;
> typedef unsigned short WORD;
>
>
> class CTestClass {
>     public:
>         enum {
>             rows = 20,
>             cols = 200 // a some extra cols, so the loop can work more
>         };
>         short *sData[rows];
>         CTestClass();
>         DWORD64 computeDistance3(short *src,const WORD wRow,const WORD
> wColFrom,const WORD wColTo) const;
>         DWORD64 computeDistance3b(short *src,const WORD wRow,const WORD
> wColFrom,const WORD wColTo) const;
> };
>
> CTestClass::CTestClass() {
>     for (int r = 0; r < rows; r++) {
>         sData[r] = new short[cols];
>         for (int c = 0; c < cols; c++) {
>             sData[r][c] = r+c;
>         }
>     }
> }
>
> DWORD64 CTestClass::computeDistance3(short *src,const WORD wRow,WORD
> wColFrom,const WORD wColTo) const {
>     DWORD64 qwDist = 0;
>     int iA;
>     short *sp = sData[wRow] + wColFrom;
>     short *end = src + wColTo;
>     src += wColFrom;
>     while (src <= end) {
>         iA = *src++ - *sp++;
>         qwDist += iA*iA;
>     }
>     return qwDist;
> }
>
> // the same function, but with a for loop
> DWORD64 CTestClass::computeDistance3b(short *src,const WORD wRow,WORD
> wColFrom,const WORD wColTo) const {
>     DWORD64 qwDist = 0;
>     int iA;
>     short *sp = sData[wRow];
>
>     for (int i=wColFrom; i<=wColTo; ++i) {
>         iA =  src[i] - sp[i]; // not playing with pointers, but with indexes
>         qwDist += iA*iA;
>     }
>
>     return qwDist;
> }
>
> int main() {
>     CTestClass tst;
>     short v[CTestClass::cols] = {4,7,3,2,1,8,3};
>     int i;
>     time_t t0,t1,t2;
>     DWORD64 r1,r2;
>
>     t0 = time(NULL);
>     printf("start\n");
>     for (i = 0; i < MAX; i++)
>         r1 = tst.computeDistance3(v,5,0,tst.cols-1);
>
>     t1 = time(NULL);
>     printf("3 (%u) %I64u\n",(unsigned)(t1-t0),r1);
>     for (i = 0; i < MAX; i++)
>         r2 = tst.computeDistance3b(v,5,0,tst.cols-1);
>
>     t2 = time(NULL);
>     printf("3b (%u) %I64u\n",(unsigned)(t2-t1),r2);
> }
> ---
>
>
> My hardware: PIII 650 MHz
>
> Compiler options: -O3 -march=pentium3 -fexpensive-optimizations
>
> Output:
> ---
> start
> 3 (241) 2850410
> 3b (210) 2850410
> ---
>
>
>
> So, again: such details (like play with pointers vs. play with indexes)
> doesn't really matter. This is what I pointed out in the previous message.
> And I asked what you guys think; once you've found the bottleneck, if worth
> optimizing it in C going into minimum syntax details, or writing directly in
> assembly code.
>
>
>
>
> Daniel K. O.
>
>
>

The order used shouldn't matter because of the large loop count. After
the first iteration, the loop and data will be cached. Any noise you see
in the numbers are just round-off errors and background noise in your
machine.

However, you should not use a 64-bit loop counter unless you compile for
an Opteron, Itanium or similar 64-bit processor. 32-bit unsigned handles 4
billion iterations which should be enough.

What compile optimization did you use? Did you inline the code or not? If
not inlined, I would expect the actual call to take up a significant
amount of time, completely masking any optimiazation of the dist-sqr loop.

In this case, the code was critical, since the original program was
consuming 50% of the time performing dist-sqr evaluation.

/Per W

On Sat, 31 May 2003, Graeme Foster wrote:

> Greetings,
>
> I ran the code you posted and my results were certainly not as impressive as
> yours.
>
> start (C++)
> 1 (37) 186
> 2 (35) 186
> 3 (32) 186
> 4 (33) 186
>
> start (C++ reverse order)
> 4 (33) 186
> 3 (32) 186
> 2 (35) 186
> 1 (36) 186
>
> start (C reverse order)
> 4 (33) 186
> 3 (32) 186
> 2 (35) 186
> 1 (36) 186
>
> I made a few changes - not to the methods but to main where I added a system
> pause and declared a loop counter so I could change the value. I ran with
> the following: DWORD64 loop = 100000000;
>
> Yes their is a difference but marginal. That difference is important if the
> code is time critical otherwise it probably doesn't really matter. More
> importantly is the algorithm, I could rewrite the code to be horrible
> inefficient (nest a for loop and then replacing the iA*iA with iA+iA).
>
> Graeme.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> 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
>

Forgot timing for one machine.

Also - as can be seen, there is seldom (just about never) any real use for
assembler optimization. With a little help and optimization tweaking, gcc
will generate optimal or nearly optimal code.

/Per W

On Sat, 31 May 2003, Per Westermark wrote:

> What we could see was that the original loop didn't allow inlining. By
> just touching it enough to get inlining, we get a 50% speed increase (for
> all but the memory-choked Celeron machine that used an older compiler).
>
> We didn't have to do much, it was just a 2-minute change to get gcc to fit
> the loop within available registers.
>
> One nice thing about newer x86 processors is that if the array elements is
> sized 2^x, the processor can use it's built-in barrel-shifter and do a
> constant-time multiply when loading values from the array, i.e. src[i],
> where it i in this case gets automatically multiplied by 2 at each access.
> Thank you Intel. This allows the removal of a src++ without any cost. But
> it doesn't always work - depending on the array-element size. Besides,
> with multiple integer pipes the processor might squeeze in the src++
> operation somewhere anyway.
>
> The previous post was without -fexpensive-optimizations.
>
> The following is tests with your modified loop:
> Compiler: gcc 3.2
> Optimization: -O3, -march=pentium3, -fexpensive-optimizations.
> Machine1 = Pentium II, 2*400MHz, PC100
> Machine3 = AMD XP2600+, PC3200 CL2.5
> Timing: In seconds wall-time.
> CPU load: >= 98%
>
> 1 billion loops, 7 columns
> Machine:  1     3
> Loop 1    198   31
> Loop 2    234   29
> Loop 3    100   12
> Loop 3b   157   28
> Loop 4    199   38
>
> 100 milion loops, 200 columns
> Machine:   1      3
> Loop 1        87
> Loop 2        93
> Loop 3        65
> Loop 3a       80
> Loop 4        73
> '
> I must say that I am puzzles why I couldn't get similar results as your
> PIII processor. However, with the expensive-opt on, the inlined code in
> main() is very, very hard to read :-( while giving just about the same
> times as from my previous mail without the flag.
>
> However, it looks like the compiler fucked up to align the 3A loop when it
> inlined it. The following is a test with -O2, i.e. no inlining - the
> non-inlined methods do align the loop.
>
> 100 million loops, 200 columns
PWM --> Corrected table.
> Machine:   1     3
> Loop 1    412   76
> Loop 2    425   75
> Loop 3    380   67
> Loop 3b   360   66
> Loop 4    370   73
>
> In this case I got an improvement from Loop 3b. However, let the numbers
> talk. I would definitely recomment inlining...
>
> /Per W
>
> On Sat, 31 May 2003, Daniel K. O. wrote:
>
> >
> >
> >  >  It is nice that you can laugh at my code. However, I DID benchmark
> >  >  the code before writing the previous mail...
> >
> >
> > Well, I didn't say that, sorry if you got pissed with what I said. I didn't
> > said that optimizing coded is useless.
> > You really did optimize some stuffs, and I didn't say that everything would
> > be automagically optimized; I pointed out that there are some minor details
> > that some people still think that can be "optimized" by just writing the
> > same commands in a different way (not necessarily a different
> > algorithm/order).
> >
> > I modified your code a little, to just show what I really said:
> >
> >
> > ---
> > #include <time.h>
> > #include <stdio.h>
> >
> > #define MAX 100000000 // your code have an extra zero, I took it out so we
> > won't measure the calling code, but the loop
> >
> >
> > typedef unsigned __int64 DWORD64;
> > typedef unsigned short WORD;
> >
> >
> > class CTestClass {
> >     public:
> >         enum {
> >             rows = 20,
> >             cols = 200 // a some extra cols, so the loop can work more
> >         };
> >         short *sData[rows];
> >         CTestClass();
> >         DWORD64 computeDistance3(short *src,const WORD wRow,const WORD
> > wColFrom,const WORD wColTo) const;
> >         DWORD64 computeDistance3b(short *src,const WORD wRow,const WORD
> > wColFrom,const WORD wColTo) const;
> > };
> >
> > CTestClass::CTestClass() {
> >     for (int r = 0; r < rows; r++) {
> >         sData[r] = new short[cols];
> >         for (int c = 0; c < cols; c++) {
> >             sData[r][c] = r+c;
> >         }
> >     }
> > }
> >
> > DWORD64 CTestClass::computeDistance3(short *src,const WORD wRow,WORD
> > wColFrom,const WORD wColTo) const {
> >     DWORD64 qwDist = 0;
> >     int iA;
> >     short *sp = sData[wRow] + wColFrom;
> >     short *end = src + wColTo;
> >     src += wColFrom;
> >     while (src <= end) {
> >         iA = *src++ - *sp++;
> >         qwDist += iA*iA;
> >     }
> >     return qwDist;
> > }
> >
> > // the same function, but with a for loop
> > DWORD64 CTestClass::computeDistance3b(short *src,const WORD wRow,WORD
> > wColFrom,const WORD wColTo) const {
> >     DWORD64 qwDist = 0;
> >     int iA;
> >     short *sp = sData[wRow];
> >
> >     for (int i=wColFrom; i<=wColTo; ++i) {
> >         iA =  src[i] - sp[i]; // not playing with pointers, but with indexes
> >         qwDist += iA*iA;
> >     }
> >
> >     return qwDist;
> > }
> >
> > int main() {
> >     CTestClass tst;
> >     short v[CTestClass::cols] = {4,7,3,2,1,8,3};
> >     int i;
> >     time_t t0,t1,t2;
> >     DWORD64 r1,r2;
> >
> >     t0 = time(NULL);
> >     printf("start\n");
> >     for (i = 0; i < MAX; i++)
> >         r1 = tst.computeDistance3(v,5,0,tst.cols-1);
> >
> >     t1 = time(NULL);
> >     printf("3 (%u) %I64u\n",(unsigned)(t1-t0),r1);
> >     for (i = 0; i < MAX; i++)
> >         r2 = tst.computeDistance3b(v,5,0,tst.cols-1);
> >
> >     t2 = time(NULL);
> >     printf("3b (%u) %I64u\n",(unsigned)(t2-t1),r2);
> > }
> > ---
> >
> >
> > My hardware: PIII 650 MHz
> >
> > Compiler options: -O3 -march=pentium3 -fexpensive-optimizations
> >
> > Output:
> > ---
> > start
> > 3 (241) 2850410
> > 3b (210) 2850410
> > ---
> >
> >
> >
> > So, again: such details (like play with pointers vs. play with indexes)
> > doesn't really matter. This is what I pointed out in the previous message.
> > And I asked what you guys think; once you've found the bottleneck, if worth
> > optimizing it in C going into minimum syntax details, or writing directly in
> > assembly code.
> >
> >
> >
> >
> > Daniel K. O.
> >
> >
> >
>
>

Hello Maxim!

Maxim Yemelyanov wrote:
> Hello, OROSZI!

Balázs :) This is my first name. We just write it the opposite way.

> I just dont know how function stack works. When I call foo(), where its stack
> starts? Just on caller's stack's free space?
> 
> Because what I thought was:
> 1) getC(1) creates a local object at address xxxx (on its stack), this object
> will be destroyed at the end of f().

No, it will be destroyed at the end of getC(1). But here is where gcc 
optimises. It does not destroy it, instead it simply "returns" it.

> 2) getC(2) creates a local object _at_the_same_ address xxxx.

No, why would it? It is a different call, different local variable. We 
would be in BIG trouble if gcc would behave like that...

> 3) Since both objects exist until end of f(), this can cause a trouble.

See above, like that, there is no problem :)

> But when I tried a simple test (added output to getC), I saw that two local
> objects are created at different addresses.

Of course. It is two DIFFERENT function calls. I was talking about the 
local variable, and the returned object. Try this:
Store the address of the local variable in getC(x), and then check the 
returned object's address too. Like this:

C* local_address;
C* returned_address;

getC(int)
{
   C c(1);
   local_address = &c;
   return c;
}

main()
{
   C c;
   c = getC(1);
   returned_address = &c;
   /* Here, local_address and global_address "should" be the same */
   /* TRY IT! */
}

> OB> I don't understand you clearly...
> That's because I don't see the whole picture (in all details). Thanks, your
> answer have cleared some areas of the topic to me :-)
> Moreover, since most of time I used pure C, such things as C++ classes and
> references, passed between functions (and optimization of all this stuff) is
> still not enough clear to me. 
> That's why I sometimes ask stupid questions. Sorry :-\

Ahh. No problem :) I am not enough familiar with C++ yet either. :)

> What are these 10%? When I should be careful about optimization?

I don't know. I haven't got any trouble with optimization yet. I have 
seen LARGE projects, that use -O3 optimisation, and they work fine. So I 
think you can safely enable it. GCC is getting better and better, and 
GCC 3.2 can be considered modern enough not to f**k up the program.

--
Greetings,
   Balázs

Greetings,

I ran the code you posted and my results were certainly not as impressive as
yours.

start (C++)
1 (37) 186
2 (35) 186
3 (32) 186
4 (33) 186

start (C++ reverse order)
4 (33) 186
3 (32) 186
2 (35) 186
1 (36) 186

start (C reverse order)
4 (33) 186
3 (32) 186
2 (35) 186
1 (36) 186

I made a few changes - not to the methods but to main where I added a system
pause and declared a loop counter so I could change the value. I ran with
the following: DWORD64 loop = 100000000;

Yes their is a difference but marginal. That difference is important if the
code is time critical otherwise it probably doesn't really matter. More
importantly is the algorithm, I could rewrite the code to be horrible
inefficient (nest a for loop and then replacing the iA*iA with iA+iA).

Graeme.

 >  It is nice that you can laugh at my code. However, I DID benchmark
 >  the code before writing the previous mail...


Well, I didn't say that, sorry if you got pissed with what I said. I didn't
said that optimizing coded is useless.
You really did optimize some stuffs, and I didn't say that everything would
be automagically optimized; I pointed out that there are some minor details
that some people still think that can be "optimized" by just writing the
same commands in a different way (not necessarily a different
algorithm/order).

I modified your code a little, to just show what I really said:


---
#include <time.h>
#include <stdio.h>

#define MAX 100000000 // your code have an extra zero, I took it out so we
won't measure the calling code, but the loop


typedef unsigned __int64 DWORD64;
typedef unsigned short WORD;


class CTestClass {
    public:
        enum {
            rows = 20,
            cols = 200 // a some extra cols, so the loop can work more
        };
        short *sData[rows];
        CTestClass();
        DWORD64 computeDistance3(short *src,const WORD wRow,const WORD
wColFrom,const WORD wColTo) const;
        DWORD64 computeDistance3b(short *src,const WORD wRow,const WORD
wColFrom,const WORD wColTo) const;
};

CTestClass::CTestClass() {
    for (int r = 0; r < rows; r++) {
        sData[r] = new short[cols];
        for (int c = 0; c < cols; c++) {
            sData[r][c] = r+c;
        }
    }
}

DWORD64 CTestClass::computeDistance3(short *src,const WORD wRow,WORD
wColFrom,const WORD wColTo) const {
    DWORD64 qwDist = 0;
    int iA;
    short *sp = sData[wRow] + wColFrom;
    short *end = src + wColTo;
    src += wColFrom;
    while (src <= end) {
        iA = *src++ - *sp++;
        qwDist += iA*iA;
    }
    return qwDist;
}

// the same function, but with a for loop
DWORD64 CTestClass::computeDistance3b(short *src,const WORD wRow,WORD
wColFrom,const WORD wColTo) const {
    DWORD64 qwDist = 0;
    int iA;
    short *sp = sData[wRow];

    for (int i=wColFrom; i<=wColTo; ++i) {
        iA =  src[i] - sp[i]; // not playing with pointers, but with indexes
        qwDist += iA*iA;
    }

    return qwDist;
}

int main() {
    CTestClass tst;
    short v[CTestClass::cols] = {4,7,3,2,1,8,3};
    int i;
    time_t t0,t1,t2;
    DWORD64 r1,r2;

    t0 = time(NULL);
    printf("start\n");
    for (i = 0; i < MAX; i++)
        r1 = tst.computeDistance3(v,5,0,tst.cols-1);

    t1 = time(NULL);
    printf("3 (%u) %I64u\n",(unsigned)(t1-t0),r1);
    for (i = 0; i < MAX; i++)
        r2 = tst.computeDistance3b(v,5,0,tst.cols-1);

    t2 = time(NULL);
    printf("3b (%u) %I64u\n",(unsigned)(t2-t1),r2);
}
---


My hardware: PIII 650 MHz

Compiler options: -O3 -march=pentium3 -fexpensive-optimizations

Output:
---
start
3 (241) 2850410
3b (210) 2850410
---



So, again: such details (like play with pointers vs. play with indexes)
doesn't really matter. This is what I pointed out in the previous message.
And I asked what you guys think; once you've found the bottleneck, if worth
optimizing it in C going into minimum syntax details, or writing directly in
assembly code.




Daniel K. O.

Check this:

http://www23.brinkster.com/noicys/devcpp/ub.htm






Ioannis Vranos

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net 

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of
Scr...@ao...
Sent: Saturday, May 31, 2003 7:12 AM
To: dev...@li...
Subject: [Dev-C++] Remove me from all mailing list!



Please remove me from all mailing list!

E Mail: Scr...@ao...

Best Regards. ~Rodney Working~ 

Check this:
 
 <http://www23.brinkster.com/noicys>
http://www23.brinkster.com/noicys/devcpp/ub.htm
 
 
 
 
Ioannis Vranos

* Programming pages: http://www.noicys.freeurl.com
<http://www.noicys.freeurl.com/> 
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net <http://www.noicys.cjb.net/>


 

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of
Scr...@ao...
Sent: Saturday, May 31, 2003 7:12 AM
To: dev...@li...
Subject: [Dev-C++] Remove me from all mailing list!



Please remove me from all mailing list!

E Mail: Scr...@ao...

Best Regards. ~Rodney Working~ 

    Does anyone know where I can find information - any website - on=20
reading/writing JPEG files?

    Thanks for any help.
    Juliano

--=20
Visite minha p=E1gina: http://www.jpavel.kit.net

Please remove me from all mailing list!

E Mail: Scr...@ao...

Best Regards. ~Rodney Working~

> -----Original Message-----
> From: dev...@li... 
> [mailto:dev...@li...] On Behalf 
> Of Ioannis Vranos
> Sent: Saturday, May 31, 2003 3:22 AM
> To: Dev-C++ Mailing List
> Subject: RE: [Dev-C++] #DEFINE versus cont variables in array 
> inicializations
> 
> 
> I just checked it and it seems you are right. Don't know why yet.
> 
> 
> However does the above style make the compiler to give it an 
> address? That
> would be very strange. I shall check the standard now.


TC++PL on pages 199,200 says that const has by default internal linkage. So
the definition must be accomanied by the keyword extern too.


So my code becomes:


temp2.cpp:

extern const int x=17;


temp.cpp:

#include <iostream>


extern const int x;


int main()
{
 const unsigned char *p=reinterpret_cast<const unsigned char *>(&x);
 
 
 // Shows x representation in memory in byte values
 // including padding bits
 for(unsigned long i=0; i<sizeof(x); ++i)
   std::cout<<static_cast<short>(p[i])<<" ";


}


C:\c>g++ temp.cpp temp2.cpp -o temp

C:\c>temp
17 0 0 0
C:\c>


So in this case the compiler can know if the const object or *reference* is
accessed in another translation unit.



However why a compiler would "inline" const int x=7; and  would not be able
to "inline" const int &x=7; isn't clear and would be nice if you explained
it to us. And please do not involve L1/L2 caches, we are talking about
inline substitution here. And my CPU may have no cache.




Ioannis Vranos
 
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

I assume gcc is a bit naughty. However, as long as I know about the
problem, it does allow me to write working code that is portable to other
compilers.

/Per W

On Sat, 31 May 2003, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: Ioannis Vranos [mailto:iv...@em...]
> > Sent: Saturday, May 31, 2003 3:13 AM
> > To: Dev-C++ Mailing List (dev...@li...)
> > Subject: RE: [Dev-C++] #DEFINE versus cont variables in array
> > inicializations
> >
> >
> > > -----Original Message-----
> > > From: Per Westermark [mailto:pw...@ia...]
> > > Sent: Saturday, May 31, 2003 6:38 AM
> > > To: Ioannis Vranos
> > > Cc: Dev-C++ Mailing List
> > > Subject: RE: [Dev-C++] #DEFINE versus cont variables in array
> > > inicializations
> > >
> > >
> > > See below
> > >
> > >
> > > If you know that you need to take the address in another file, then
> > > declare it as:
> > >     extern const int SIZE = 7;
> >
> >
> > I am sorry to tell you this, but this is *nonsense*. The C++
> > standard doesn't require to define it like this.
>
>
>
> I just checked it and it seems you are right. Don't know why yet.
>
>
> However does the above style make the compiler to give it an address? That
> would be very strange. I shall check the standard now.
>
>
>
>
> Ioannis Vranos
>
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL 1: http://run.to/noicys
> * Alternative URL 2: http://www.noicys.cjb.net
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> 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
>

Please.

I'm not talking about C++ standard.
I'm talking about a real gcc 3.2 behaviour.
This isn't what I think but what my compiler does:

--- def.cc ---
const int x = 7;
--- ref.cc ---
#include <stdio.h>
extern const int x;
int main() {
    printf("value x = %d\n",x);
    printf("addr x = %p\n",&x);
    return 0;
}
--- build ---
>g++ -c def.c
>g++ -c ref.c
>g++ def.o ref.o -lstdc++ -o test.exe
--- result ---
ref.o(.text+0x3f):ref.cc: undefined reference to `x'
ref.o(.text+0x54):ref.cc: undefined reference to `x'
--- def.s ---
        .file   "def.cc"
        .text
        .align 4
_x:
        .long   7
--- ref.s ---
        .file   "ref.cc"
        .def    ___main;        .scl    2;      .type   32;     .endef
        .text
LC0:
        .ascii "value x = %d\12\0"
LC1:
        .ascii "addr x = %p\12\0"
        .align 2
.globl _main
        .def    _main;  .scl    2;      .type   32;     .endef
_main:
LFB1:
        pushl   %ebp
LCFI0:
        movl    %esp, %ebp
LCFI1:
        subl    $8, %esp
LCFI2:
        andl    $-16, %esp
        movl    $0, %eax
        movl    %eax, -4(%ebp)
        movl    -4(%ebp), %eax
        call    __alloca
        call    ___main
        subl    $8, %esp
        pushl   _x
        pushl   $LC0
LCFI3:
        call    _printf
        addl    $16, %esp
        subl    $8, %esp
        pushl   $_x
        pushl   $LC1
        call    _printf
        addl    $16, %esp
        movl    $0, %eax
        leave
        ret
LFE1:
        .def    _printf;        .scl    2;      .type   32;     .endef
--- end ---

As you can see, def.cc doesn't export the const int x.

If I instead make the following change, everything will work ok, since
now, x is exported from def.o.

--- def.cc ---
extern int x = 7;
--- def.s ---
        .file   "def.cc"
.globl _x
        .text
        .align 4
_x:
        .long   7
--- end ---

/Per W

On Sat, 31 May 2003, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: Per Westermark [mailto:pw...@ia...]
> > Sent: Saturday, May 31, 2003 6:38 AM
> > To: Ioannis Vranos
> > Cc: Dev-C++ Mailing List
> > Subject: RE: [Dev-C++] #DEFINE versus cont variables in array
> > inicializations
> >
> >
> > See below
> >
> >
> > If you know that you need to take the address in another file, then
> > declare it as:
> >     extern const int SIZE = 7;
>
>
> I am sorry to tell you this, but this is *nonsense*. The C++ standard
> doesn't require to define it like this.
>
>
> I can define a const object in the global namespace:
>
> const int x=7;
>
>
>
> and in another file I can do this:
>
>
> #include <iostream>
>
>
> extern const int x;
>
> // ...
>
>
> void f()
> {
>    const unsigned char *p=reinterpret_cast<const unsigned char *>(&x);
>
>
>  // Shows SIZE representation in memory in byte values
>  // including padding bits
>    for(unsigned long i=0; i<sizeof(x); ++i)
>       std::cout<<static_cast<short>(p[i])<<" ";
> }
>
>
>
>
>
>
>
> > It doesn't. Either make sure that the file that declares SIZE
> > takes it's
> > address, or declare it as 'extern const int SIZE = 7;'
>
>
>
> Please direct me in the C++ standard where it mentions such a requirement.
>
>
>
>
> Ioannis Vranos
>
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL 1: http://run.to/noicys
> * Alternative URL 2: http://www.noicys.cjb.net
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> 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
>