Author: Vincent Diepeveen
Date: 08:41:43 08/01/03
Go up one level in this thread
On August 01, 2003 at 09:52:00, Uri Blass wrote: cut the crap just show your speed. period. if you cannot do it fast then how can you scan in evaluation fast? >On August 01, 2003 at 09:19:54, Vincent Diepeveen wrote: > >>On July 30, 2003 at 02:50:34, Tony Werten wrote: >> >>>On July 29, 2003 at 22:31:46, Vincent Diepeveen wrote: >>> >>>>On July 29, 2003 at 20:16:59, Matthew White wrote: >>>> >>>>>On July 29, 2003 at 16:53:05, Vincent Diepeveen wrote: >>>>> >>>>>>On July 29, 2003 at 03:15:54, Hristo wrote: >>>>>> >>>>>>>On July 28, 2003 at 19:12:56, Vincent Diepeveen wrote: >>>>>>> >>>>>>>>On July 28, 2003 at 17:34:46, Russell Reagan wrote: >>>>>>>> >>>>>>>>>Is there any reason to start new projects with C anymore? It seems like most (if >>>>>>>>>not all) of the drawbacks of C++ have faded away with modern compilers. >>>>>>>>> >>>>>>>>>Note that I am talking about new projects, and maintaining old projects is >>>>>>>>>obviously a good reason to still use C. >>>>>>>> >>>>>>>>If i would learn coding today i would prefer C++. >>>>>>>> >>>>>>>>However let's be clear, for good programmers there is not much diff between C >>>>>>>>and C++. Every complex problem which you can solve in 10000 lines of C++ you can >>>>>>>>solve in 10000 lines C too. >>>>>>>> >>>>>>> >>>>>>>Vincent, >>>>>>>with all due respect I must disagree. In 10K lines of C++ code one can solve a >>>>>>>much more general or larger set of problem(s) or cram in more features. :) >>>>>>>(think templates, exceptions, and often inheritance ... all of which can shorten >>>>>>>your code) >>>>>> >>>>>>I do not know about you, but i program both in C and C++. >>>>>> >>>>>>Do you? >>>>>> >>>>>>Not a single program where you can use all the nice toys you can also make a few >>>>>>functions for in C. >>>>>> >>>>>>In general the average programmed C++ program you program more compact in C. >>>>>> >>>>>>That's not what i'm talking about. >>>>>> >>>>>>If you do not know how to program in C, then just say it loud instead of writing >>>>>>it down like this. >>>>>> >>>>>>the advantages of what you mention here (assuming 1 man products) you can show >>>>>>great in 50 line examples or even 200 line examples. >>>>>> >>>>>>But as soon as you write a 10000 line product then it doesn't matter what you do >>>>>>in C++. I can do the same in C too. No problem! >>>>>> >>>>>>>In your post, latter, you indicate that C++ offers some advantages over C, >>>>>>>especially for large projects. In my experience this is %100 true, so we are in >>>>>> >>>>>>I see no other advantages to C++ than for big projects in fact. >>>>>> >>>>>>The advantage is *really* huge there for companies. >>>>>> >>>>>>Given the importance of those companies for the world, the choice to teach >>>>>>students C++ instead of C is a logical choice. >>>>>> >>>>>>teaching them Java, delphi i find a bad idea. >>>>>> >>>>>The best reason that I see to teach students using Java is that Java gives you >>>>>useful information when an error occurs (remember the first time you saw a >>>>>segmentation fault how lost you felt?). Java has strong typing and it FORCES >>>>>object orientedness. C and C++ are too frustrating for new programmers... >>>>> >>>>>Matt >>>> >>>>I agree fully with Bob here. His Pascal argument is very valid. >>> >>>No it isn't. Neither are yours. Both of you haven't programmed in Pascal for a >>>long time, so I don't understand how your opinions are formed, but anyway. >> >>Tony let's skip the perft nonsense, but let's do a simple test. >> >>Just generate after the move e4 e5 d4 d5 with your NORMAL semi legal move >>generator the move list 10 million times. >> >>Then divide the number of semi legal moves * 10 mln by the time needed. >> >>How many moves a second can you generate then at your hardware? >> >>2.127Ghz K7 ==> 73 MLN nodes a second. >> >>Let's be clear this is my *normal* move generator which stores the move and an >>ordering score. >> >>I'm close to a few tenth of cycles a generation, which is the misprediction >>usual for assumption that there is a capture move possible. Which in only 2 >>cases isn't mispredicted. >> >>Without that storing of the moves and without that misprediction it goes up to a >>few cycles a move. >> >>Majority of pascal coders that have no extensive C or C++ experience are very >>buggy programmers. They are not even *close* to the same level like most C/C++ >>programmers. >> >>They miss for example the understanding of how the processor works... > >I find the test irrelevant because of some reasons: >1)it is not clear what it pseudo legal move generator. > >Do you generate move that put the king under threat? >A program with attack table may not generate move that put the king under >threat. > >It can still be pseudo legal move generator if the program does not have pin >information and does not check if a piece is pinned before generating moves. > >In the relevant position checking if e2 or d2 are under attack of black may be a >waste of time but in other cases checking it is not a waste of time and it can >help you to be faster in generating moves(I assume that you have arrays that >tell you if a square is under attack of the opponent). > >2)You can do your make move slower in order to do the move generator faster >by updating information(for example you can have incremental move generator so >you remember before 2...d5 the list of moves of both side and you only need to >generate the difference between the list of moves of white before 2...d5 and >after 2...d5 and update the ordering score). > >3)You may do your move generaotor slower for having better ordering scores > >Uri
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.