A basic optimization request...

This is a discussion on A basic optimization request... within the C++ Programming forums, part of the General Programming Boards category; Originally Posted by brewbuck Translation: write something unacceptable, then throw it all away and do it right. Might as well ...

  1. #16
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,901
    Quote Originally Posted by brewbuck View Post
    Translation: write something unacceptable, then throw it all away and do it right. Might as well skip that pointless first step.
    Absolutely not.
    Again, it's the whole premature optimizing part.
    Choose the right container and structure is obviously. Any good software will do that. But when it comes down to micro-optimizing, it's better to know where to apply them rather than applying them everywhere to save yourself headache and trouble.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  2. #17
    The larch
    Join Date
    May 2006
    Posts
    3,573
    If I'm not mistaken, new in C++ is quite different from one in C#. In C# it is the default way of creating objects, in C++ it is not.

    (If you see a benchmark where Java or C# outperforms C++ greatly, often the reason may be that small-object allocation with new is a lot slower in C++.)

    Like I said, write code first, optimize later.
    One should also avoid premature pessimisation.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  3. #18
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,263
    Quote Originally Posted by Elysia View Post
    Absolutely not.
    Again, it's the whole premature optimizing part.
    Choose the right container and structure is obviously. Any good software will do that. But when it comes down to micro-optimizing, it's better to know where to apply them rather than applying them everywhere to save yourself headache and trouble.
    We DO know where to apply them. People have known this stuff for decades. We don't have to feign ignorance of the issues.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  4. #19
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,901
    Fine fine, whatever.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  5. #20
    Registered User
    Join Date
    Mar 2010
    Posts
    68
    well well. I am amazed at the people who are bashing on Elysia. What she is saying is absolutely correct -- write code first, optimize later.

    I think there are many on this board who don't understand what this means. If you don't, do a search for code optimizing techniques. You will find that program optimization happens from the top down, not the bottom up. What this means is that you create an outline of the basic functionality of the program you are attempting to create. Then, after that is done, you can now optimize the program correctly because you have an idea of how the program flows. Anyways, I have nothing to add to this discussion other than that, which is exactly about how much a few others have contributed to this thread.

    If links to web pages of people who are smarter are needed, I will provide them. But, that is of course with the assurance that something will be learned and taken from this.

  6. #21
    Making mistakes
    Join Date
    Dec 2008
    Posts
    476
    Write it in C xD

    Elysia is right. Write first, optimize later. Debugging (and you will do that a lot) is much more important than speed. A program that crashes in 9 ms less time is not useful.

    Just thinking that a routine will be called often is not a good solution. Use a profiler. You will be surprised at how much time passes in little functions you ignored.

    That means, you can optimize on-the-fly. That would be f.i. choosing the right containers, pass by reference or pointer, inline small functions etc. which would not make it difficult to debug.

    Also, in my experience, more than 50% of my code is thrown away immediately, so coding everything in assembly or complicated expressions is not the best solution. Maybe some people are not that wasteful, but in my case, hey, I'm not perfect.

    Or you could fill your code with #ifdefs and use a threaded dispatch mechanism for all switch-case-labels for each architecture and compiler. That may be used in a final version, but debugging it will be a pain.

    Anyway, the switch-case-thingies might as well go as this:
    Code:
    static const ptrdiff_t table[] = {&offsetof(BitBoard, WhitePawns), offsetof(...)};
    if (Piecetype > 13)
        return NULL;
    return *(unsigned long long *)((char *)Board + table[Piecetype]);
    One comparison, two adds and two deferences. That should be fast enough. But, if you change something in BitBoard, aka make it a real class, you have to rewrite this routine.

    And inline those functions. The getter/setter ones always.
    Last edited by Brafil; 05-04-2010 at 01:46 PM.

  7. #22
    The larch
    Join Date
    May 2006
    Posts
    3,573
    Elysia is right. Write first, optimize later. Debugging (and you will do that a lot) is much more important than speed. A program that crashes in 9 ms less time is not useful.
    Depends on the kind of things we are talking about. If, for some reason, you had to implement your own sorting function for large datasets, there's no point to start out writing a bubble-sort, even though it is simplest and easiest to debug.

    I also don't think in chess there would be much reason to start out with a "simpler" data representation because the whole thing is all about the representation and algorithms on it. If you find out later that you need to change the representation, you are going to have to rewrite it all, so the easy debuggability gives no benefit.

    These are not micro-optimizations.

    Anyway, the switch-case-thingies might as well go as this:
    And there you go suggesting a micro-optimization, that the compiler may already be performing for you, perhaps even better...
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  8. #23
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,263
    Quote Originally Posted by Brafil View Post
    Write it in C xD

    Elysia is right. Write first, optimize later. Debugging (and you will do that a lot) is much more important than speed. A program that crashes in 9 ms less time is not useful.
    A chess program that loses is lame.

    Given two chess players, which are identical in all respects except that one uses bit boards and one does not, the version using bit boards will win. Every time. Guaranteed. Calling bit boards a micro-optimization is like saying that having walls on your house is "convenient." Uh, no. You need walls. You need bit boards.

    Just thinking that a routine will be called often is not a good solution. Use a profiler. You will be surprised at how much time passes in little functions you ignored.
    The only point in profiling would be to verify that indeed, almost all of the time is spent in the heuristic evaluator. If it isn't, then your program clearly has a bug in it. So I suppose it could be a useful test in that respect.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  9. #24
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,359
    Given two chess players, which are identical in all respects except that one uses bit boards and one does not, the version using bit boards will win. Every time. Guaranteed.
    You were doing pretty well up to this point. That comment was stupid. It would be very difficult to create an implementation that is "identical in all [other] respects", but if they are "identical in all [other] respects" then the choice is a trivial implementation detail.

    Elysia:

    The point of the bitboards is not an optimization of size or simple comparisons. A lot of great algorithms are known that take advantage of the representation or depend on the representation. It is like starting with "Quicksort" instead of "BubbleSort" if you know the data to be sorted isn't already mostly sorted. It isn't premature optimization. It isn't even optimization. It a decision based on knowledge of the problem. It is, as you say, "[choosing] the right container and structure".

    Soma

  10. #25
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,308
    The reason that it is not premature optimisation to start out with bit boards in this case is because it is a very common problem which has already been researched thoroughly, and it is well known ahead of time that this is necessary to have a decent chess engine.
    It could be premature optimisation if you were amoung the first to write it and there was no pre-existing research about it. But in this case, not using bit-boards initially would simply be a failure to do prior research first.
    I would not expend the significant effort required to code up a non-bit-board solution first for any other reason either.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  11. #26
    Making mistakes
    Join Date
    Dec 2008
    Posts
    476
    I didn't call bitboards premature optimization. I just wanted to say that feeder shouldn't try to optimize too much while the program isn't safe, but I suspect it is.

    Choosing Bubblesort instead of Quicksort would not be "I'm not optimizing prematurely", but rather something stupid you should never do. I didn't say that choosing the right data-structure or algorithm is premature optimization.

    All I wanted to say is to make sure that your program runs 99% right. No bugs in it or whatsoever, as far as that's possible. After that, you can go as far as you want with optimization.

    Code:
    And there you go suggesting a micro-optimization, that the compiler may already be performing for you, perhaps even better...
    I like optimization.

  12. #27
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,359
    O_o

    Who are these people who said you said all these things?

    Choosing Bubblesort instead of Quicksort would not be "I'm not optimizing prematurely", but rather something stupid you should never do.
    Except... you know... when you should.

    Soma

  13. #28
    Making mistakes
    Join Date
    Dec 2008
    Posts
    476
    OK, there are a few exceptions of course, but in general you should prefer Quicksort over Bubblesort and a tree over an unordered linked list.

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

Similar Threads

  1. Function call from another .c module
    By Ali.B in forum C Programming
    Replies: 14
    Last Post: 08-03-2009, 12:45 PM
  2. Can you check what is wrong with this code
    By Ron in forum C++ Programming
    Replies: 4
    Last Post: 08-01-2008, 11:59 PM
  3. [ANN] New script engine (Basic sintax)
    By MKTMK in forum C++ Programming
    Replies: 1
    Last Post: 11-01-2005, 10:28 AM
  4. what are your thoughts on visual basic?
    By orion- in forum A Brief History of Cprogramming.com
    Replies: 16
    Last Post: 09-22-2005, 05:28 AM

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