Critter: Pascal vs C

[rvida]

In the past 2 months I was experimenting with bitboards. At the point I had working board class and captures/evasions/checks generator, I fell in love with them. My only concern was speed. I am very disappointed with the performance of delphi compiled code. Looking through the disassembly of generated code the compiler seems to be 15 years behind any decent C compiler out there. Inlining sucks, register allocation is poor, dependency chains are HUGE. It cannot even unrool simple loops with constant number of iterations (for i:=WHITE to BLACK). Not to mention absence of 64bit target...

Then I decided to learn C and try to port Critter. So far I have working perft and the results are _very_ promising.

There are the test result fors perft(5) in 300 WAC positions:

Code: Select all

        |        Pascal       |      C 32bit       |      C 64bit
--------+---------------------+--------------------+------------------                 
time    |   1220163 ms        |   730547 ms        |   536157 ms
speed   |     18793 knodes/s  |    31338 knodes/s  |    42769 knodes/s

While I expected _some_ improvement, this is simply outrageous, the 64bit C version is more than 2x faster !

[Carey]

Not many people would say that Delphi is a high performance compiler.... Or any of the old 'Turbo' tools, for that matter.

You might get better results from FreePascal. It also has a 64 bit version for both Windows and Linux. The Lazarus development environment is much weaker than most C environments, though.

It's not a high performance compiler either, but it should be faster than Delphi, especially once you do the 64 bit version.

There is nothing inherent in Pascal that would cause a major performance penalty. Modern versions of Pascal (as opposed to the classic versions) have all the operators and features you need to write fast code. The source will be more 'wordy' than C, but there is nothing inherently in C that results in faster programs than Pascal does.

(And just like with C++, modern Pascal has its share of exciting features that are poorly designed and even more poorly implemented and should be avoided at all costs.)

C's performance is mostly due to the quality of the compilers.

And there aren't many who would argue C's superiority in that area.


I admit I am an ex-Pascal lover. I used to love the type checking that could be done in Pascal. It wasn't as strict as classic Pascal, but it was enough to prevent you from doing the obvious idiotic things that C encourages.

After this many years, my brain has been permanently damaged by C's laughable type checking and I doubt I could port a C chess program to Pascal now.

[bob]

Not many people would say that Delphi is a high performance compiler.... Or any of the old 'Turbo' tools, for that matter.

You might get better results from FreePascal. It also has a 64 bit version for both Windows and Linux. The Lazarus development environment is much weaker than most C environments, though.

It's not a high performance compiler either, but it should be faster than Delphi, especially once you do the 64 bit version.

There is nothing inherent in Pascal that would cause a major performance penalty. Modern versions of Pascal (as opposed to the classic versions) have all the operators and features you need to write fast code. The source will be more 'wordy' than C, but there is nothing inherently in C that results in faster programs than Pascal does.

(And just like with C++, modern Pascal has its share of exciting features that are poorly designed and even more poorly implemented and should be avoided at all costs.)

C's performance is mostly due to the quality of the compilers.

And there aren't many who would argue C's superiority in that area.


I admit I am an ex-Pascal lover. I used to love the type checking that could be done in Pascal. It wasn't as strict as classic Pascal, but it was enough to prevent you from doing the obvious idiotic things that C encourages.

After this many years, my brain has been permanently damaged by C's laughable type checking and I doubt I could port a C chess program to Pascal now.

Remember that C was never intended to be a tightly-defined idiot-proof language. It was designed to let you write portable code, while getting as "close" to the hardware as you wanted to get to obtain max performance and flexibility. No one would begin to claim that assembly language has any useful type-checking or constraints, and C was designed to eliminate the assembly language itself, without hurting the performance you could expect. The older "register" declaration is a good example of how close to assembly it would let you get.

I hated Pascal. I know what I want to do when programming, and I don't want the compiler to get in the way and make me jump through hoop after hoop. Writing a compiler in Pascal was a syntactical challenge. Writing one in even Fortran was much more pleasant, and in C it was a wonderful project for students.

[Carey]

Remember that C was never intended to be a tightly-defined idiot-proof language. It was designed to let you write portable code, while getting as "close" to the hardware as you wanted to get to obtain max performance and flexibility. No one would begin to claim that assembly language has any useful type-checking or constraints, and C was designed to eliminate the assembly language itself, without hurting the performance you could expect. The older "register" declaration is a good example of how close to assembly it would let you get.

I know that and I agree with most of that.

I do take exception that they couldn't have added a little safety. Even asm macro languages can have some safety to keep you from making mistakes. Like trying to transfer a FPU register to a cpu register. Or trying to treat an address register like an ALU register. Or...

I also have to take exception about it being designed for portability. The original C was nearly antithetic for portability. It went out of its way to be very PDP'ish. It wasn't designed 'on' the PDP, but *for* the PDP.

It took a lot of effort in the K&R era to reach tolerable portability levels. In both the language and the library. And it took 10 years for the first C standard to work out enough of the flaws in k&r to make it into a somewhat portable language. Even function prototypes was a radical idea!


C was designed to let the user do nearly anything they wanted with no concern for whether it was *right*. That's a very poor design goal.

Over the years, C has added some safety, but very little. And along with that, they've even abstracted some stuff, in the name of portability. It's permissible for the compiler writer to actually hide some of the CPU stuff. (Think NULL is always zero. Nope. It can be anything. But it has to behave *exactly* as if it was, including transparent conversion when you use it or try to check its real value.)

I hated Pascal. I know what I want to do when programming, and I don't want the compiler to get in the way and make me jump through hoop after hoop. Writing a compiler in Pascal was a syntactical challenge. Writing one in even Fortran was much more pleasant, and in C it was a wonderful project for students.

I agree the classic versions of Pascal (like you used) are a PITA to use.

That Pascal should never have been developed.

Years ago I tried using an ISO version of Pascal. (shudder!) That was even worse than the original.

(Just look at all the hoops that Larry Atkin had to jump through to write Chess 0.5 That's an excellent example of how bad the Pascal language used to be.)


Fortunately, modern versions (started with TurboPascal) have left much of that idioticy behind. Not all, but much of it.

There are still types and you can't blindly (or accidently) confuse a char and an integer unless you choose to. If you want a small integer, then you *say* you want a small integer and not a text character.

If you say a var is going to represent a color, you aren't going to be able to accidently put a piece type in there.

You can still do what you want, with the compiler catching mistakes. Like this C code:

#define WHITE 1
#define PAWN 1

int SideBasedVar[...]; /* White / Black */

func() { if (SideBasedVar[PAWN]) .... }


Pascal, then and now, does require you to think a bit differently.

That's part of the point and the problem. After years of C programming, it is *hard* to think logically and properly and not like C's "Everything is an int" attitude.

You can write proper code in C, but it doesn't encourage it and it wont notice if you don't. It even encourages you to not write properly.

That's why I said I've been brain damaged by C.

In the old days, I could write Pascal code pretty well. It all made sense and I thought that way and writing was easy. I didn't have to jump through hoops or struggle with the compiler to let me do something. (My first Pascal compiler was slightly more advanced than the classic ones. It had relaxed type checking like what is common these days.)

After 20+ years of C programming though, Pascal is no longer easy for me. I've been brain damaged.

[mcostalba]

(And just like with C++, modern Pascal has its share of exciting features that are poorly designed and even more poorly implemented and should be avoided at all costs.)

What are in your opinion the features of C++ poorly implemented and that should be avoided at all costs ?

Just curiosity, I absolutely don't want to start a discussion on languages (is one of the most scaring and useless things to do BTW).

But I am just curious to know someone with a C background what finds difficult of poorly designed in C++.

Thanks
Marco

[Carey]

(And just like with C++, modern Pascal has its share of exciting features that are poorly designed and even more poorly implemented and should be avoided at all costs.)

What are in your opinion the features of C++ poorly implemented and that should be avoided at all costs ?

Just curiosity, I absolutely don't want to start a discussion on languages (is one of the most scaring and useless things to do BTW).

But I am just curious to know someone with a C background what finds difficult of poorly designed in C++.

Thanks
Marco

I think this would get into too much of a C++ vs. anti-C++ flame war.

It's been discussed here before and opinions vary quite a bit.

Some feel the features are fine and perfect. Others feel they are okay provided you know exactly what your particular compiler is doing, and others, such as myself, feel some things are just poorly designed and that the C++ standard involved too much invention without any implementation to test things with first.

I do readily admit that I am not now, nor have I ever been, a fan of C++.

If other people (not you, just 'others') don't like that... (shrug) I can live with that.

[mcostalba]

I absolutely don't want any kind of flame war or c++ vs anything else.

In my opinion everybody is more productive with the language that he likes, whatever this language is.

I was just asking


P.S: An hint to avoid discussion is to answer with the name of the features someone (I have asked to Hyatt but of course I am interested in anyone's opinion) thinks are poorely designed instead of something vague and so prone to be discussed like "many features", "a lot of thing" or other sentence with very small information content in.

[Carey]

I absolutely don't want any kind of flame war or c++ vs anything else.

In my opinion everybody is more productive with the language that he likes, whatever this language is.

I was just asking


P.S: An hint to avoid discussion is to answer with the name of the features someone (I have asked to Hyatt but of course I am interested in anyone's opinion) thinks are poorely designed instead of something vague and so prone to be discussed like "many features", "a lot of thing" or other sentence with very small information content in.

There have been several discussions in these chess forums (and the previous ones.) They never persuade anyone that their favorite language is bad, of course....

Even Hyatt & me have discussed Pascal a few times. He always complains about UCSD and ISO Pascal, and I always say that it's improved since then. Nothing new really happens here when it comes to discussing languages.

But alright, I will say that I intently dislike the way templates are done, as well some of the overloading.

When you have to guess which gets called and promoted and so on, something is seriously wrong with the language.

I also don't like how some things in C++ may not result in the nice, simple, quick code you expect. It is possible to stay with a reasonably safe & efficient subset of C++, though.

Some of the class stuff is okay, but that's certainly not enough to make me actually like C++.

And I read too much about the C++ standardization process while it was happening, and the invention it was doing (rather than standardization), and the politicing that was going on to have any warm feelings about C++.

And, of course, back then if you used C++ you were locked into one specific version of one vendor's compiler. Nobody else was implementing the same draft features and with draft versions of C++ being released every hour on the hour, you knew the next version of the vendor's C++ compiler would implement things differently and probably break your code.

Some of my dislike is technical and some of it due to a very bad taste in my mouth that I got way back then.

No language is perfect. Not Pascal, not C, and not C++. C++ just happens to have a few more imperfections than any other programming language in existance, that's all....

[Steve Maughan]

I am a little surprised at the difference between the Delphi code and C. I would have estimated that Delphi had about a 20% speed penalty - this data would suggest that it's a little higher. That said, Delphi is an excellent overall development environment - IMHO the best for WIn 32 development. A speed penalty of 30% is nothing for most apps. I have written mathematical optimization apps in Delphi and the speed is fine despide no FPU optimization.

Cheers,

Steve

[rvida]

I am a little surprised at the difference between the Delphi code and C. I would have estimated that Delphi had about a 20% speed penalty - this data would suggest that it's a little higher. That said, Delphi is an excellent overall development environment - IMHO the best for WIn 32 development. A speed penalty of 30% is nothing for most apps. I have written mathematical optimization apps in Delphi and the speed is fine despide no FPU optimization.

Cheers,

Steve

I bet the mailbox version would not see that big difference. In my mailbox move generator the main bottleneck is branch misprediction. It doesnt matter much whether the pipelines are fully utilized since the CPU must flush them very often.

Bitboard approach is much less branchy but has more L1 misses. Well optimized instruction stream does a good job hiding latencies.

I wish I had more time to play with tools such as vtune or cachegrind...