Author: Vincent Diepeveen
Date: 07:16:27 05/19/04
Go up one level in this thread
On May 19, 2004 at 09:54:30, Reinhard Scharnagl wrote: i hope you realize nalimov egtb code when used makes executable sizes quite some larger. default diep is like its latest version: 16-05-2004 23:05 335.872 diepm_16may2004.exe but when i compiled once with nalimov egtb code a few months ago : 21-02-2004 01:48 2.002.944 diepm_20feb04_wb.exe Only difference : egtb.cpp I did compile without -O2 by the way for the c++ code. So anyone using C++ you are going to doom? >On May 19, 2004 at 09:33:19, Vincent Diepeveen wrote: > >>On May 19, 2004 at 08:38:55, Reinhard Scharnagl wrote: >> >>>On May 19, 2004 at 07:15:54, Vincent Diepeveen wrote: >>> >>>>On May 19, 2004 at 01:02:26, Reinhard Scharnagl wrote: >>>> >>>>You obviously never wrote a chessprogram writing such utter nonsense at your >>>>homepage about executable size. >>> >>>Vincent, please cool down. >>> >>>Obviously you know neither me nor my experiences with that theme. >>> >>>May be you have not noticed, that I am always talking of the size of the >>>persistent data and exe AFTER COMPRESSING it, e.g. by WinRar. >>> >>>Regards, Reinhard. > >>I'm not using winrar but RKC. >> >>See for example : http://www.maximumcompression.com/programs.php > >You can choose what you want, but a self decompressing version would >be best. WinRar simply has been an example. Compression should be >needed only for the measuring act, that is all. winrar is no realtime executable compressor. >>So whatever your uncompressed size, mine will be up to 4 to 10 times smaller in >>size than your outdated compression standards. > >Great. Then 1/4 MB seems to be quite reachable for you. yes and when started after a few years with that 1/4 MB i can also generate a GB or 10 of egtb's (all 6 men). another few years and all 7 men are there too. >>If i want to compress fast i'm using 7-zip btw. >> >>Also a single compile option can matter 500KB in size easily. >> >>Further moving from x86 hardware to IPF hardware means executable size for same >>program with same compiler already grows a factor 2-3. >> >>That's without being optimized of course with PGO. >> >>When you optimize with PGO your executable at IPF grows bigtime in size. >> >>Now so far we still discussed just C software. >> >>How about C++ guys, or delphi guys? >> >>They make no chance in your definition.... > >You will notice that the higher the language level is, the more you are >able to compress the resulting exe. Therefore measuring the size of the What will be left after compression will still be considerable larger. >compressed files would make you more independent from the decision, which >language you have selected for development. Other criteria there will be >more important. >Regards, Reinhard. In short you have a lot of crap statements at your homepage. It's loaded with it. I didn't find anything intelligent at your homepage. For example try to lookup the difference between a preprocessor in chess and non preprocessor. You invented a new name for it without realizing what you were looking for. >>>>>On May 19, 2004 at 00:29:42, Joshua Shriver wrote: >>>>> >>>>>>Are there any kind of hardware limitations in computer competitions? >>>>>> >>>>>>If not, I'd imagine people would just bring a small custom cluster. >>>>>> >>>>>>TSCP would beat Hiarcs or Shredder if tscp was parallelized and Hiarcs was on a >>>>>>486. >>>>>> >>>>>>Just an idea; perhaps there should be some kind of limitation. >>>>>>If not then you're not really testing the strength of the engines, but a >>>>>>combination of code and hardware. In that case, whoever has the most money has a >>>>>>huge advantage. Especially if clustering is allowed. >>>>>> >>>>>Just my $0.02, curious to your opinions. >>>>> >>>>>Have you ever seen my limitation proposal to that theme at: >>>>> >>>>>[http://homepages.compuserve.de/rescharn/Compu/schachfair_e.html] >>>>> >>>>>Regards, Reinhard.
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.