Not logged inRybka Chess Community Forum
Up Forum
Search - powered by Google™
Topic On lazy SMP scaling strawman arguments By bob Date 2016-10-11 16:36
I generally use TTD (or its cousin TTS [time to solution]).  All that matters is how long it takes to either get the PV for the requested depth, or the time to get the PV for the solution.  I really don't care about what the non-PV moves are searched to, any more than in a normal 1 thread search where the extensions and reductions already make the term depth pretty unclear.

My preferred benchmark has always been positions with one best move, period.  One that takes some computation time to solve.  Then as I make changes, if it solves the position quicker (and I am ONLY talking about parallel search changes here) then I can easily measure whether the change is good or bad.  The "time to depth" can't be compared between programs since "depth" is not a constant (the old "king" engine was a good example, where it often did 1-2 ply searches that took minutes and which were tactically quite solid back in those days.  But the time to depth is perfectly reliable for the same program.

I'm not giving up on normal parallel search myself.  I (and others) have posted a ton of Crafty data producing a 13x+ speedup on 20 cores, and some recent 32 core testing produced a speedup of 21x.  Those are pretty proportional and I hope to have some 64 thread results in a few months.  Nobody seems to post any data on lazy smp programs so there is little to compare to.

As far as "attacks" I only comment on those that lie.  IE "my program is completely original" where someone on open chess trivially refutes that showing the early houdinis had MUCH code taken from the robbolito family of chess engines.  Remember that?  If you had simply owned up to using Robbo* as your original source, all of that could have been avoided.  Seems that honesty is a pretty rare characteristic in some cases.
Topic Crafty's development problem revisited By bob Date 2015-04-12 19:03
Finally have a few minutes to educate you (and a couple of others) here.

This "development" as you call it is NOT an evaluation problem.  That simply shows you do NOT understand the search.  So for some education:

Say you add an evaluation term that says "if knight is on g1, subtract a penalty for white, if not, no penalty."  That does NOT work as you might expect.

For a human chess player, we give consideration to WHEN we move a piece, knowing that it is better to develop pieces first and then do other things later.  Not a chess program.  Not ANY chess program.

A chess program only evaluates at end points.  So it either sees that knight on g1 and gives a penalty, or it has been moved and it gets no penalty.  No clue about WHEN the knight was moved.  Could have been the first move at the root, or the last move in the q-search.  All are the same to the program, it is there when we apply the eval (at endpoints) or not.

Now take two programs like Crafty and Stockfish.  Stockfish greatly out searches Crafty in terms of depth.  Let's just pick some numbers and say that in position P Crafty searches 30 plies, stockfish hits 40.  That will wreck the development problem WITHOUT it being an evaluation issue.  Crafty has 30 moves to move pieces around and then assess development.  Stockfish has 40.  And each move sees Stockfish greatly out-searching Crafty, causing Crafty to have to continually first address some tactical or positional threat that it did not see on its last move, before getting to the development.  But it DOES get to the development before ply 30, and is happy.  But Stockfish keeps seeing more, and each time that developing move near the end of the PV keeps getting postponed.  And in some cases, it gets postponed forever.  This is not quite a horizon-effect issue, but it is related.  A pure search depth problem.

Now why can't it realize that moving the knight at ply=1 is better than moving it at ply=30?  Our good friend the transposition table, which only stores positions, but not paths.  When you hash a position at ply=20, the moves from ply=1 to 20 are unknown, only the resulting position is there.  How to penalize not moving the knight earlier?  Because you don't know WHEN it was moved in the first place, only that it either was or was not.

So please get off this evaluation stuff.  You have absolutely no clue about how a chess engine works, yet you make what you think are knowledgeable comments that are 100% wrong.  You should stick to analyzing human games.  There your comments would be correct.  But NOT in a computer chess game.

Now before you respond, at least make sure you understand the above.  Then this particular side-show can end...  Only problem I see is that I don't think I have enough time left in my life to fill in all the computer chess holes you have in your lack of knowledge.
Topic BayesElo, LOS, etc. By bob Date 2014-09-07 05:06
I actually looked at the games and watched the score.  And the score simply got too high from a build-up that eventually turned out to be not sustainable.  I've seen other examples.  Some evaluation terms or search strategies are good no matter what, just so they are included.  Some are very sensitive.  King safety is the most touchy because get it wrong conservatively and you play passively and let your opponent attack without defending very well.  Get it too optimistic and you can either sacrifice material or pawn structure for a king attack that will fizzle out, or you defend against an imaginary attack and wreck your position trying to prevent something your smarter opponent never even tries.  In some cases "real hot" works just fine for some terms.  In other cases "real cold" works just fine.  But some require the "baby bear" approach where it has to be just right, neither too hot nor too cold, both of which might well be fatal.

I think gauntlet testing offers far more accuracy, because you introduce a new idea and discover how a group of opponents respond to that, collectively.  And note that I do NOT test multiple changes at once.  One change per test.  Only one degree of freedom to worry with.  BTW, a side question, based on something I pointed out elsewhere.  How would you feel about taking a group of games between two opponents with variable time controls, but by variable, I mean randomly variable.  Say from 15 secs per game to 60 or 120 seconds per game, not an equal number of games at each time control, no control over how many games are played at each possible time control, etc.  Would you consider that a "noisy" test environment?  I'll explain why after you answer.
Topic Stockfish gets ...checkmated! By bob Date 2014-05-15 17:57
The definition of "original source code" is pretty well defined.  Code not written by others, not copied from others, not derived from the code of others via reverse-engineering, non-literal copying, etc.  Has absolutely NOTHING to do with playing against other programs.  If that were the case, there would be NO original programs on the planet. 

1.  Everybody tunes their code by playing games against others.  Whether it be on local machines (as Crafty, Komodo, Rybka, Stockfish, etc) or on remote machines such as ICC, FICS, etc.

2.  Many tune their opening books against other opponents and prepare book lines that lead to easy wins for their program. 

For "plagiarism" here you go from a well-known copyright infringement consultant (Bob Zeidman):

plagiarism is “the practice of claiming, or implying, original authorship, or incorporating material from someone else’s written or creative work in whole or in part, into ones own, without adequate acknowledgment.”  Essentially, plagiarism means unauthorized copying, and no software tool can determine whether authorization was given. Also, plagia- rism can occur when only parts of a work have been copied – in some cases with numerous changes. It occurred to me that my tool is really a “correlation determination” tool that can perform a quantitative analysis and pro- duce a number representing the amount of correlation between the source code files for trewo different programs. An expert is still needed to determine the reason for the correlation.

This is NOT about "ideas" or "competing with others".  Get a dictionary and learn to use the right words.

Feel FREE to show anyone else's work in the Crafty source code, particularly, citing your post above, anything whatsoever from the fruit 2.1 code base.  Once you can do that, you will have a point.  BTW as far as Crafty vs Crafty, you DO realize that Vas often used "Rybka vs Rybka"?  It is just not as reliable and can lead you down false pathways.

You really have no point.  You really have no idea what you are talking about.  And you really don't understand that.  You might as well be arguing about intricacies of heart-lung transplanting with Dr. John Kirkland.  Or computer architecture with the late Seymour Cray.  Etc.  Until you understand at LEAST a little about the problem domain area, you will never be able to make a valid point.  And in the case of computer software, you are quite clearly WELL out of your area of expertise, based on the comments you make here.  Using your ridiculous definition, we could not have computer chess tournaments of any kind, because speaking for myself, every time I play in a tournament, I discover potential improvements for my program.  Gasp.  Derived from others...  You can use this argument all you want, I don't believe one other person on the planet agrees with you.  That should show you where this idea stands in terms of merit.
Topic Non tablebase. By bob Date 2014-02-26 02:55
You need to ask someone much wiser than I am to answer that question, unfortunately.  I've not done any detailed statistical analysis of computer / gm games.  I only know what I have seen as I have watched hundreds of such games over the years.  Most machine victories come when the human simply makes a mistake.  In some games the computer plays outstanding chess and wins, although again, I believe it is always a case of someone losing rather than someone winning.  In some cases, the computer plays poorly and loses.  But the biggest majority of the games experience a sudden score jump which signals the previous human move was likely a mistake...

Be interesting to try to answer what you are asking, but there are lots of interesting questions left in computer chess to answer as well...
Topic I have a question regarding CPU affinity By bob Date 2014-01-10 19:10
1.  The primary point of processor affinity is local cache utilization.  If you are using Intel, then each physical core has its own L1/L2 caches.  If you run your process on core 1 for a bit, you "warm up" that cache by getting your data loaded into it.  If the operating system then bounces your process to another core, things slow down for a bit as you have to again warm up that cache and get your data in it.  The idea of processor affinity is a two-layer affair.  A "good" operating system won't bounce processes around.  Linux is a good example.  So for the most part, worrying about it is a waste of time and energy on your part.  But if you want to make absolutely certain, you can bind a process to a physical core, which is equivalent to binding it to a specific L1/L2 (and even L3 in some cases) cache, where the operating system loses the freedom to run the process anywhere but the specific core you specified when you did the set affinity.

2.  hyper-threading is just a sub-set of this, where you have two logical cores that share the resources of one physical core, which means also sharing the L1/L2 cache.  Again, a good O/S (I am not a windows user, so I can't speak for windows process scheduling) such as Linux will handle this by itself, again making it something not worth thinking about.

3.  If you have a 6 core box, with hyper threading (SMT in intel-speak) enabled, the operating system treats it like 12 physical cores in terms of total computational power available.  If you just run 6 threads under linux, the operating system is smart enough to run the 6 threads on 6 physical cores (not using the hyper-threaded cores at all).  And yes, it will show that you are only using 50% of the CPU cycles since 1/2 of the total cores are idle.

4.  Note that not all operating systems are very good at this.  Apple OS/X seems to be quite lousy.  I can run two threads and watch the 4 logical cores (this is a macbook air, dual-core + hyper threading box) run the two physical threads more or less randomly, where on linux I see two physical cores lock on to those threads and their "hyper-threaded partner" remains 100% idle.

5.  Hyperthreading does increase power dissipation.  You are using physical resources inside the CPU more heavily.
Topic Stockfish 161213 sees off Houdini 4 in 41 moves! By bob Date 2013-12-30 17:11
How can I suggest something when I have no way to test to come up with such?  As I said, if you want to use stockfish 4, I can certainly take some time, run some tests, and discover exactly what is needed.  I therefore didn't "decline".  I was "unable to suggest anything due to absolutely no data to base my suggestion on."

BTW houdini's eval is not significantly different than Crafty's, based on Robolito.  Some compare stockfish search to houdini and talk about the depth difference.  I think that's a red herring that is not so important.  The simplest example is program A that extends all checking moves by 1 ply, nothing else.  Program B reduces all non-checking moves by 1 ply, nothing else.  Given a fixed time limit, B will search "deeper".  Both will produce the same score/PV.  Depth reported is irrelevant.  What is important is what is searched, what is searched deeper than most, what is searched shallower than most.  For example, stockfish reduces aggressively, much more so than most.  But then they have code that "un-reduces" for some cases when they notice something about the sub-tree below a reduction, such as when the next ply has a null-move fail-low.  It's an interesting topic.

My personal observation after looking at lots of stockfish vs crafty games is just what I stated above, stockfish's search is simply better and does a better job of searching the right things than Crafty does.  I don't see any evidence of a superior evaluation at all.  And in some cases, Crafty's is actually better, particularly related to parts of pawn structure recognizing weak pawns.

Perhaps if robolito is now stable, I can compute a handicap for it, if anyone has any idea of a handicap between robolito and Houdini.  That's as far as I can go as I need source to run anything on my cluster, I have to be able to compile it.
Topic Letters and trophies By bob Date 2013-09-09 21:37
There you go.  I said "FSF will go to court in some cases."  NOT directed at the rybka/fruit case.

Once again, you get caught with distortions.  What a loser...

I didn't say "They WILL take Vas to court, now did I?"  Exaggeration.  Distortion.  Out-of-context.  Typical.
Topic Move similarity between Hiarcs and Houdini By bob Date 2013-09-09 19:29
It is a SOFTWARE issue.  I found the SOFTWARE issue that caused Fruit to crash.  The underlying cause was gross over-extension.  Rybka stops searching in some cases, and crashes in others.  The underlying cause was gross over-extension.  Same underlying cause.  VERY rare underlying cause.  Yet they both share the same problem and get out to that SAME grossly excessive (>200 plies) depth...

You have an acute lack of comprehension about terminology.  A programmer turns an algorithm into code.  That's his job.  If the algorithm allows unlimited extensions, the programmer should catch that when he writes/tests the code.  If the algorithm has a cutoff and the programmer missed it, he should catch that when he writes/test the code.  The issue is BOTH fruit AND rybka have the SAME flaw.  That's odd, at best, and to me pretty suspicious.  To you, who knows nothing about chess programming, no so much most likely.

As far as algorithm vs coding issues, there is NO WAY to tell what is wrong here.  All we know for certain is that the PROGRAMMING has a bug.  It over-extends.  Whether the programmer wrote the code wrong, or the algorithm was incorrectly specified is irrelevant.  The PROGRAMMING is wrong.  And both programs share this "identical wrongness" which suggests that even more code was copied, part of the search...
Topic Bob's suggested punishment By bob Date 2013-08-21 19:13
What is your point?  Discussions were taken offline in some cases, because not doing so would have led to a ton of posts that almost no one would have cared about.  All the Crafty evidence, for example.  The final result was made available to everyone.  All the bits and pieces that were discovered would only serve as clutter.  You can see how that can happen on this forum, in fact...
Topic Zach Wegner about the Panel By bob Date 2013-01-12 15:36
Sorry, but that is simply dead wrong.  A judge has no say-so over who gets into the jury box.  Attorneys can, in some cases, challenge and remove jurors.  For various reasons including whether or not they support the death penalty.  However, if a gas station owner is on trial, one doesn't exclude anyone that owns a gas station because they compete against each other.  Your claim is pure nonsense.

A juror doesn't have to prove ANYTHING.  All he is constrained to do is listen to the proceedings, examine the evidence, and render a verdict.  He is NOT required to explain how he reached his decision, nor why.  In fact, most jury decisions are reached via secret ballot.  The only clue about votes is for those cases that require a unanimous verdict, such as a criminal conviction (as opposed to a civil action which does not).

What I questioned was Marcel's reasoning about considering something that had absolutely no bearing on the question we were supposed to address.  If he wants to change his vote, that's fine.  He should have done so AT THE RIGHT TIME, when it would have counted.

"opposition" and "reasonable doubt" are not the same thing.  People politic all the time, trying to get a convicted killer off of death row.  Not because they disagree with his being guilty, but because they disagree with the punishment.  The panel didn't hand down the punishment, the ICGA board did.  The panel just provided a report along with a list of those that thought the evidence presented proved that Rybka was not original according to rule 2.
The ICGA report is a giant document (set, actually) that does offer convincing evidence that Rybka was based on Fruit (and early versions that were based on Crafty).  It is not 100% proof, because that is impossible. It certainly rises above "beyond a reasonable doubt" however, because each point of "refutation" offered here are implausible at best, and impossible in some cases.

I didn't go through the investigation without realizing anything.  The report CLEARLY states what you claim we didn't realize, so if there is any stupidity here, that would be on your part, not ours...
First, BFL has offered exactly NOTHING.  No technical issues.  NOTHING but rambling, bumbling nonsense.  He is not capable of offering any technical information regarding x86 asm, reverse engineering, and the like.  So I have absolutely no idea what you mean by "BFL's examples."  He has no "examples" in that debate.

Nobody has pointed out any significant mistake in the ICGA data.  The code derived from the rybka binary is, with almost no level of uncertainty, semantically equivalent to the C code from Fruit.  In some cases it is perfectly matching.  In some cases, the bitboard translation has to be factored in.  To date, nothing has been shown to be incorrect in the C code shown compared to the Rybka binary.

Just because you are unwilling to accept it does NOT mean it is wrong.  You seem to care very little about the things Vas has done, yet want to make a mountain out of a molehill about the one similar PST in Crafty, which is a tiny, tiny fraction of the similarities shown between Rybka 1.0 beta and Fruit.  And of course you want to completely ignore Vas' claim that ALL VERSIONS of Rybka were 100% original, even the pre-fruit versions.  And that has shown to be completely false.  And his entering events with directly copied code in those other versions is also OK.  In fact, everything he has done is 100% OK with you, it seems.  One thing is for sure, however.  That is YOUR opinion.  It is not the opinion of the majority of computer chess researchers/developers...

BTW, I DO consider that to be a good idea about admitting mistakes.  Vas should stand up and do exactly that and then we all move on.  BTW it seems that report was false, as Lance's attorney has said no such statement is forthcoming.
Topic Houdini 3 has been released By bob Date 2012-10-16 19:13
Sorry, but everything is EXACTLY the same, except for the apparent financial situation of the person buying the service.  Everything else is IDENTICAL in this case.  No extra or different effort.  No extra equipment.  You charge more if you believe you can get more.  Guy drives up in a Caddy, you charge him more for a wax than you do if a guy drives up in a 20 year old ford.  I get that.  Doesn't mean it is not "cheesy or greedy" however.  As I said.

In some cases this becomes illegal, of course.  Don't try to sell a $10 sheet of plywood for $100, or a $500 generator for $2500 right after a hurricane.  Greed can go too far at times.  I can recall a couple of instances in planning a funeral where a funeral director told me that for a pre-planned service (before the person dies) you pay one price, if you wait for "at time of need" it costs much more.  Does it REALLY cost them any more if I pay before someone dies tomorrow, or after?  yes I understand the concept of paying early lets them collect interest.  I also understand greed...

It won't ever go away.
Topic Rybka & ICGA at the FIDE Ethics Commission By bob Date 2012-08-23 02:25
You can repeat that until you believe it, but no one else will buy it.  Zach's report INTENTIONALLY shows code side-by-side.  In some cases to show the non-literal copying we discussed, but in some cases, showing exact literal matches.  Like it or not.
Topic discussions about rule 2 By bob Date 2012-01-29 03:10
That's a difference between bitboards and mailbox.  Never said otherwise.  I was using bitboards 10 years before Rybka existed.  I understand EXACTLY what the advantages are.  Bitboards have been around since the early 70's (actually earlier as Samuels used them in his checkers program).  Are you a lousy "engineer"?  Why didn't you use them?  There are valid arguments for each way.  And once you choose the methodology, some things become simpler with one than with the other.  Working with "sets" is a bitboard concept.  Working with "lists" is a maiklbox concept.  Either works.  In some cases, one is faster than the other, in other cases, not...

Rybka doesn't need "just one instruction".  It has to do the rotated bitboard lookups (two times, once for each diagonal).  That is fairly expensive accesses into large arrays.  Then it ORs them together to produce the set of attacked squares.  Then it does the popcnt.  NOT "one instruction".  Dump the asm and you will see.

MY mobility doesn't do that two lookups, and the OR, and the popcnt.  It just looks up the mobility directly, which has been pre-computed.  A 16 bit memory load and I am totally done.  You need to stop trying to lecture ME on how bitboards work.  I've only been doing 'em 17 years longer than you.  The popcnt() is the least of the issues with generating mobility. For anyone that understands the underlying idea...  Creating the set of attacked squares is the hard work.  Both in bitboards AND mailbox since that is where the loops come from in mailbox...

If you measure speed, you will find MY mobility is faster.  Why?  Because what he does is what I did so long ago, and still do today:

score+=BISHOP_MOBILITY*MobilityBishop(square);

What you see today is a prototype:

    mobility = MobilityBishop(square, OccupiedSquares);
    if (mobility < 0 && (pawn_attacks[enemy][square] & Pawns(side)) &&
        (File(square) == FILEA || File(square) == FILEH))
      mobility -= 8;
    score_mg += mobility;
    score_eg += mobility;

Something Tracy played with that does MORE than just mobility.  The first line, BY ITSELF, is the equivalent of all that code Vas uses.  The if() is checking for a very restricted mobility, and if so, AND the bishop is on one of the sides of the board, the mobility is reduced even further.

You don't even understand what the code is doing, so no wonder you can't make a valid comparison.

If you want an exact rybka or fruit equivalent from Crafty:

    mobility = MobilityBishop(square, OccupiedSquares);
    score_mg += mobility;
    score_eg += mobility;

Is ALL I need, and it is significantly simpler than what Rybka does in terms of cycles required...

Sorry to crash your party again...

BTW if we decide to keep the above code, the extra mobility scoring will just get folded into the mobility lookup, and the code will again look just as above.  Tracy changed / tweaked the scores in the obvious place for testing...
Topic discussions about rule 2 By bob Date 2012-01-28 16:14
I don't know what to say.  I was given proofs to work out all through college.  I did not copy the solutions of others.  If I ran into a problem I could not figure out, we had group meetings to discuss such things.  But the meetings were to understand the problem, and how to attack it to reach a solution, not to have someone write the answers on the board.  Something told me that would not be beneficial when exam time came along.  I was right.

You continue to not understand the comparison we did.  And you continue to use the WRONG concept in the first place.

RE is about taking a binary and turning it into a source program that one can read or modify.  We did NOT do that.  We took the Fruit source, and the Rybka asm (from the binary) and compared them looking for semantic equivalence.  Has nothing to do with "reverse-engineering" as you are using the term.  That's been a red herring from the get-go, because that was not done ANYWHERE in the investigation.  There are no "mistakes to be made" when semantic equivalence techniques (which are well-known and frequently used by compiler people) are followed.

We never tried to prove that "our solution" was the ONLY valid one.  We only wanted to prove that the Rybka binary matches the Fruit source perfectly in some cases, or semantically (due to bitboard vs mailbox differences) in others.  At that point, one could argue one of the two following positions:

(1) Vas copied fruit, translated it to bitboards, and we base this on the exact semantic matches in so many of the evaluation terms, or in the case of crafty / rybka 1.6.1, the exact matches everywhere.

(2) Vas just serendipitously developed a program that just happens to match fruit so exactly, and Crafty perfectly, without copying.  Even though this has never been seen by anyone familiar with programming, it is possible.  And with that "it is possible" I agree.  It is also JUST as probable that a meteor is going to hit the earth's atmosphere, not burn up, and hit the ground as a meteorite in my back yard.  And that I will have a diamond about 3 feet in diameter to use for my retirement.  It is possible.  Because you can't prove it is impossible since meteorites are displayed in museums around the world.  But just how probable?

(1) is by FAR the more probable explanation.  Out into the 99.99999% probable range.  That is "good enough" for most people...  The more probable something is, the more likely that is the actual explanation...
Topic Shouting in the Dark By bob Date 2011-03-22 14:49
The "statute of limitations" does not start when the crime is committed.  It starts when it is discovered, or when it reasonably should have been discovered.   In some cases, it starts when charges are filed to prevent the investigation from going on forever.
Topic Focus of Rybka's competitor authors By bob Date 2011-03-20 15:56
You can suspect what you want.  The final report will be released publicly, once the ICGA reaches a decision.  What you are going to see in the report is exact examples of copied code.  In some cases, with explanations by me explaining why this code is absolutely unique and could not have been developed by another programmer (the previously mentioned bugs, + the unnecessary Edwards egtb code).  We are not including "we believes" or "we thinks".  Only "we sees"...

Do you realize how long that would take?  It is not a 1 month job to rewrite and debug that much code...  The idea is patently ridiculous.  Even moreso the idea that ChessBase is going to care.  The author probably has to provide some statement claiming original authorship.  That protects ChessBase.

The R1B investigation shows much more than what you state.  Not all of which is public yet.  You will eventually get your chance to see it all.

We have not published all of our data.  The "new stuff" we are including in our report, where it will become public after the ICGA releases it.  There is more than what we have discussed here.

Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill