how to increase

This is a discussion on how to increase within the C Programming forums, part of the General Programming Boards category; a.txt has 10 lines and 5 columns, and its contents is as follows: Code: 12E3F 1E34F 34EF5 ...... Code: int ...

  1. #1
    Registered User
    Join Date
    Aug 2009
    Posts
    168

    how to increase

    a.txt has 10 lines and 5 columns, and its contents is as follows:
    Code:
    12E3F
    1E34F
    34EF5
    ......
    Code:
    int main(int argc,char *argv[])
    {
       //define pointer-to-pointer **p
       readIntoMemo("a.txt",p);
    
       //now *p = "12E3F"
       //now *(p+1) = "1E34F"
       //....
    
       //how to find position of 'E' very quickly?
       //   
       return 0;
    }
    how to find position of 'E' very quickly?


    my findPosition function is as follows:
    Code:
    struct pos
    {
         int posOfLine;
         int posOfColumn;
    };
    
    //define struct 
    struct pos p[10];
    
    void findPosition(char **p,struct pos *ps)
    {
        for ( int i = 0 ; i < 10 ; i++ )
       {
          for ( int j = 0 ; j < 5 ; j++ )
         {
             char a = *(*(p+i)+j);
             if ( a == 'E' )
             {
                  ps->posOfLine = i;
                  ps->posOfColumn = j;
                  ps++;
            }
         }
       }
    }
    is there more quick method?

    is code below quick to determine a char ?
    char a = *(*(p+i)+j);
    Last edited by zcrself; 01-12-2010 at 01:03 AM.

  2. #2
    Registered User
    Join Date
    Sep 2006
    Posts
    8,868
    Exactly what is the quickest method, depends on your system, and your compiler. While the allure for more speed is great, great optimizations also mean great loss of clarity and ease of maintenance in your code.

    I would be decidedly grumpy if someone wanted help with code like this:
    char a = *(*(p+i)+j)

    What's next, will you be programming in assembly? Maybe machine language?

    With the strong PC's we have today, there are few functions in C that run too slowly.

    Test it out for yourself, but I will hazard a guess that using an array and indeces, will be equally fast.

  3. #3
    Registered User jeffcobb's Avatar
    Join Date
    Dec 2009
    Location
    Henderson, NV
    Posts
    875
    strchr()?
    C/C++ Environment: GNU CC/Emacs
    Make system: CMake
    Debuggers: Valgrind/GDB

  4. #4
    Registered User
    Join Date
    Aug 2009
    Posts
    168
    Quote Originally Posted by jeffcobb View Post
    strchr()?
    is strchr function more quicker than "char a = *(*(p+i)+j);"

  5. #5
    Registered User jeffcobb's Avatar
    Join Date
    Dec 2009
    Location
    Henderson, NV
    Posts
    875
    Quote Originally Posted by zcrself View Post
    is strchr function more quicker than "char a = *(*(p+i)+j);"
    No idea, never tried it. Any situation where I needed to find a char, it was fast enough.
    C/C++ Environment: GNU CC/Emacs
    Make system: CMake
    Debuggers: Valgrind/GDB

  6. #6
    Registered User jeffcobb's Avatar
    Join Date
    Dec 2009
    Location
    Henderson, NV
    Posts
    875
    is it just me or did this post subject initially look like spam from an inbox?
    C/C++ Environment: GNU CC/Emacs
    Make system: CMake
    Debuggers: Valgrind/GDB

  7. #7
    Password:
    Join Date
    Dec 2009
    Location
    NC
    Posts
    587
    Quote Originally Posted by zcrself View Post
    is strchr function more quicker than "char a = *(*(p+i)+j);"
    I imagine compilers are really confused by complex one liners like that, in hlls it's not always the least instructions, but the best ordered instructions that produce the most efficient code. The only way to know for sure would be to learn the ins and outs of your choice compiler.

    If it really matters that much then use asm, I've never mixed asm with c but the asm of what you're asking for should be
    Code:
    mov di, &File
    Next_Char:
    lodsb
    cmp al, 'E'
    jne Next_Char
    inc &E_count
    cmp al, 0 ; This assumes files end with 0, idk
    jne Next_Char
    I have no idea how to integrate that with c(especially gcc, it uses at&t syntax, so if you're using gcc, this is completely useless to you), but if your this obsessed with optimization you'll end up doing it in asm anyway. I suggest Fasm.

  8. #8
    Registered User jeffcobb's Avatar
    Join Date
    Dec 2009
    Location
    Henderson, NV
    Posts
    875
    Quote Originally Posted by User Name: View Post
    I imagine compilers are really confused by complex one liners like that, in hlls it's not always the least instructions, but the best ordered instructions that produce the most efficient code. The only way to know for sure would be to learn the ins and outs of your choice compiler.

    If it really matters that much then use asm, I've never mixed asm with c but the asm of what you're asking for should be
    Code:
    mov di, &File
    Next_Char:
    lodsb
    cmp al, 'E'
    jne Next_Char
    inc &E_count
    cmp al, 0 ; This assumes files end with 0, idk
    jne Next_Char
    I have no idea how to integrate that with c(especially gcc, it uses at&t syntax, so if you're using gcc, this is completely useless to you), but if your this obsessed with optimization you'll end up doing it in asm anyway. I suggest Fasm.
    I haven't done this in years but I THINK it used to be as simple as:
    Code:
    __asm
    {
         // asm instructions go here
    }
    But don't quote me on that...
    C/C++ Environment: GNU CC/Emacs
    Make system: CMake
    Debuggers: Valgrind/GDB

  9. #9
    Registered User
    Join Date
    Sep 2006
    Posts
    8,868
    In Turbo C, it's just

    Code:
    asm mov ax, _stklen
    
    //or
    
    asm {
       pop ax; pop ds
       iret
    }

  10. #10
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    Quote Originally Posted by User Name: View Post
    I imagine compilers are really confused by complex one liners like that, in hlls it's not always the least instructions, but the best ordered instructions that produce the most efficient code. The only way to know for sure would be to learn the ins and outs of your choice compiler.

    If it really matters that much then use asm, I've never mixed asm with c but the asm of what you're asking for should be
    Code:
    mov di, &File
    Next_Char:
    lodsb
    cmp al, 'E'
    jne Next_Char
    inc &E_count
    cmp al, 0 ; This assumes files end with 0, idk
    jne Next_Char
    I have no idea how to integrate that with c(especially gcc, it uses at&t syntax, so if you're using gcc, this is completely useless to you), but if your this obsessed with optimization you'll end up doing it in asm anyway. I suggest Fasm.
    No you won't. Unless you need access to SSE or other things you'll more than likely be slowing it down. These days compilers do a pretty good job, chances are they have more knowledge of the machine than the programmer. Not to mention the standard C functions are (usually) designed to take advantage of your architecture.

    Probably the fastest (portable) standard way is to use strchr() and fread() BUFSIZ bytes at a time.
    Last edited by zacs7; 01-12-2010 at 11:38 PM.

  11. #11
    Password:
    Join Date
    Dec 2009
    Location
    NC
    Posts
    587
    It wouldn't matter anyway, the code I posted above would result in an infinite loop.

    working code
    Code:
    mov di, &File
    Next_Char:
    lodsb
    cmp al, 0
    je Finished
    cmp al, 'E'
    jne Next_Char
    inc &E_count
    Finished:
    @jeffcobb: gcc uses at&t syntax, so the warning only applies if he uses gcc. Intel and AT&T Syntax shows some good examples of the difference. "_asm"(I think it's just "asm" in C, but don't quote me either) works fine in all compilers I know of, I just wanted to specify that if he's using gcc, there is absolutly no chance of my code helping.

    @zacs7:How could I possibly slow down a program with >40 bytes. Compilers can never be as optimized as hand coded asm, see flat assembler - View topic - HLLs suck! a whole thread devoted to exposing the faults of hlls(I don't agree with the title though, lol). Not that I'm saying that the above code is "optimized", nor that it would even matter on today's machines if the compiler added a whole kb to the function.

  12. #12
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    Shocking waste of time, and you've just ruined the portability. Even within the same architecture with another compiler. Why are you even suggesting assembly? This is a C forum, the ability to inline assembly makes no difference. Even if it does, it's for the worse.

    "How could I possibly slow down a program with >40 bytes."
    Easy, you could be using registers that the compiler was going to use for optimisations. Just one of many ways. Surely you mean less than 40 bytes. And considering the slowest part of this problem is reading the file from disk, why are you bothering?

    There is nothing wrong with:
    Code:
    #include <stdio.h>
    #include <string.h>
    
    struct position
    {
       int row,
           column;
    };
    
    int find_character(FILE * fp, const char ch, struct position * pos);
    
    int main(void)
    {
       struct position pos;
       FILE * fp = fopen("test.dat", "r");
    
       if(find_character(fp, 'E', &pos) == 0)
          printf("Found 'E' at %d:%d\n", pos.row, pos.column);
       else
          printf("'E' not found.\n");
    
       fclose(fp);
       return 0;
    }
    
    /* returns non-zero on error */
    int find_character(FILE * fp, const char ch, struct position * pos)
    {
       char buffer[BUFSIZ];
       char * search = NULL;
       int line = 0;
    
       while(!search && fgets(buffer, sizeof buffer, fp))
       {
          search = strchr(buffer, ch);
          ++line;
       }
    
       /* found it */
       if(search)
       {
          pos->row = line;
          pos->column = (search - buffer) + 1;
          return 0;
       }
    
       return 1;
    }
    And of course, the test:
    Code:
    zac@breeze:benchmark (0) $ gcc -O2 standard.c -o standard
    zac@breeze:benchmark (0) $ time ./standard
    Found 'E' at 15238266:3
    
    real	0m3.961s
    user	0m3.783s
    sys	0m0.120s
    zac@breeze:benchmark (0) $ time ./standard
    Found 'E' at 15238266:3
    
    real	0m4.033s
    user	0m3.846s
    sys	0m0.147s
    zac@breeze:benchmark (0) $ time ./standard
    Found 'E' at 15238266:3
    
    real	0m3.865s
    user	0m3.770s
    sys	0m0.097s
    zac@breeze:benchmark (0) $ uname -a
    Linux breeze 2.6.31-ARCH #1 SMP PREEMPT Tue Nov 10 19:48:17 CET 2009 i686 Intel(R) Atom(TM) CPU N270 @ 1.60GHz GenuineIntel GNU/Linux
    Run on a test.dat:
    Code:
    zac@breeze:benchmark (0) $ du -s test.dat 
    104280	test.dat
    zac@breeze:benchmark (0) $ head -n 10 test.dat 
    ABC135
    ABC135
    ABC135
    ABC135
    ABC135
    ABC135
    ABC135
    ABC135
    ABC135
    ABC135
    ...
    
    With line 15238266 containing an 'E' at column 3.
    And this computer isn't especially fast (being a netbook with a 5200RPM hard drive). I only have gcc, so I can't bench yours

    An idea of the disk speed:
    Code:
    root@breeze:benchmark # hdparm -tT /dev/sda
    
    /dev/sda:
     Timing cached reads:   1106 MB in  2.00 seconds = 552.89 MB/sec
     Timing buffered disk reads:  160 MB in  3.03 seconds =  52.77 MB/sec
    Last edited by zacs7; 01-13-2010 at 10:42 PM.

  13. #13
    Registered User
    Join Date
    Aug 2009
    Posts
    168
    Quote Originally Posted by zacs7 View Post
    Shocking waste of time, and you've just ruined the portability. Even within the same architecture with another compiler. Why are you even suggesting assembly? This is a C forum, the ability to inline assembly makes no difference. Even if it does, it's for the worse.

    "How could I possibly slow down a program with >40 bytes."
    Easy, you could be using registers that the compiler was going to use for optimisations. Just one of many ways. Surely you mean less than 40 bytes. And considering the slowest part of this problem is reading the file from disk, why are you bothering?

    There is nothing wrong with:
    Code:
    #include <stdio.h>
    #include <string.h>
    
    struct position
    {
       int row,
           column;
    };
    
    int find_character(FILE * fp, const char ch, struct position * pos);
    
    int main(void)
    {
       struct position pos;
       FILE * fp = fopen("test.dat", "r");
    
       if(find_character(fp, 'E', &pos) == 0)
          printf("Found 'E' at %d:%d\n", pos.row, pos.column);
       else
          printf("'E' not found.\n");
    
       fclose(fp);
       return 0;
    }
    
    /* returns non-zero on error */
    int find_character(FILE * fp, const char ch, struct position * pos)
    {
       char buffer[BUFSIZ];
       char * search = NULL;
       int line = 0;
    
       while(!search && fgets(buffer, sizeof buffer, fp))
       {
          search = strchr(buffer, ch);
          ++line;
       }
    
       /* found it */
       if(search)
       {
          pos->row = line;
          pos->column = (search - buffer) + 1;
          return 0;
       }
    
       return 1;
    }
    And of course, the test:
    Code:
    zac@breeze:benchmark (0) $ gcc -O2 standard.c -o standard
    zac@breeze:benchmark (0) $ time ./standard
    Found 'E' at 15238266:3
    
    real	0m3.961s
    user	0m3.783s
    sys	0m0.120s
    zac@breeze:benchmark (0) $ time ./standard
    Found 'E' at 15238266:3
    
    real	0m4.033s
    user	0m3.846s
    sys	0m0.147s
    zac@breeze:benchmark (0) $ time ./standard
    Found 'E' at 15238266:3
    
    real	0m3.865s
    user	0m3.770s
    sys	0m0.097s
    zac@breeze:benchmark (0) $ uname -a
    Linux breeze 2.6.31-ARCH #1 SMP PREEMPT Tue Nov 10 19:48:17 CET 2009 i686 Intel(R) Atom(TM) CPU N270 @ 1.60GHz GenuineIntel GNU/Linux
    Run on a test.dat:
    Code:
    zac@breeze:benchmark (0) $ du -s test.dat 
    104280	test.dat
    zac@breeze:benchmark (0) $ head -n 10 test.dat 
    ABC135
    ABC135
    ABC135
    ABC135
    ABC135
    ABC135
    ABC135
    ABC135
    ABC135
    ABC135
    ...
    
    With line 15238266 containing an 'E' at column 3.
    And this computer isn't especially fast (being a netbook with a 5200RPM hard drive). I only have gcc, so I can't bench yours

    An idea of the disk speed:
    Code:
    root@breeze:benchmark # hdparm -tT /dev/sda
    
    /dev/sda:
     Timing cached reads:   1106 MB in  2.00 seconds = 552.89 MB/sec
     Timing buffered disk reads:  160 MB in  3.03 seconds =  52.77 MB/sec
    Your answer is very exciting , thanks !

  14. #14
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    20,968
    Quote Originally Posted by zcrself
    is strchr function more quicker than "char a = *(*(p+i)+j);"
    It sounds like you do not really know what strchr and your statement do.

    Given a pointer to the first character in a string (or substring), and a character, strchr will return a pointer to the first character in that string that is equal to the character provided, or it will return a null pointer if no such character exists.

    With routine compiler optimisations, your rather "impressive" expression *(*(p+i)+j) is equivalent to p[i][j], hence you should use p[i][j]. If you use strchr then you would not need to access individual characters in the string yourself since strchr would be doing that job for you. What you would need to do is to subtract the pointer to the first character of the string in order to obtain the index of the character, assuming that the pointer returned is not a null pointer.

    Quote Originally Posted by User Name:
    Compilers can never be as optimized as hand coded asm
    I think you mean to say that "compilers can never optimise as well as hand coded asm", but that is not necessarily true. Rather, hand coded assembly can always be optimised to be no worse than what compilers can optimise.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  15. #15
    Registered User
    Join Date
    Aug 2009
    Posts
    168
    Quote Originally Posted by laserlight View Post
    It sounds like you do not really know what strchr and your statement do.

    Given a pointer to the first character in a string (or substring), and a character, strchr will return a pointer to the first character in that string that is equal to the character provided, or it will return a null pointer if no such character exists.

    With routine compiler optimisations, your rather "impressive" expression *(*(p+i)+j) is equivalent to p[i][j], hence you should use p[i][j]. If you use strchr then you would not need to access individual characters in the string yourself since strchr would be doing that job for you. What you would need to do is to subtract the pointer to the first character of the string in order to obtain the index of the character, assuming that the pointer returned is not a null pointer.


    I think you mean to say that "compilers can never optimise as well as hand coded asm", but that is not necessarily true. Rather, hand coded assembly can always be optimised to be no worse than what compilers can optimise.
    In same conditions, *(*(p+i)+j), p[i][j] and strchr which is most quickly for finding indexes of one character. and why?

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. CPU increase with precomputed tables?
    By since in forum C++ Programming
    Replies: 17
    Last Post: 11-20-2009, 07:51 PM
  2. Increase Message Queue Size
    By Yarin in forum Windows Programming
    Replies: 3
    Last Post: 12-15-2008, 09:06 AM
  3. Minimum Wage Increase (US)
    By Cheeze-It in forum A Brief History of Cprogramming.com
    Replies: 21
    Last Post: 07-31-2006, 06:02 PM
  4. Increase Font Size Or Bold???
    By stickman in forum C++ Programming
    Replies: 10
    Last Post: 08-27-2004, 05:26 PM
  5. any useful tips to increase speed when parsing files
    By Shadow12345 in forum C++ Programming
    Replies: 2
    Last Post: 01-18-2003, 04:52 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21