Subject: RE: [hackers-il] RE: Re: My Wish-list for the O'Reilly Open Sourc e Co nvention

From: Chen Shapira <[email-masked]>
Date: Tue, 19 Nov 2002 17:00:41 +0200

> I indeed re-invented the wheel times and again. However, many 
> people are
> not aware of all the C tricks out there, and could use a 
> bag-full of them
> to learn from. I initially thought some things would 
> definitely not work
> and then discovered that they did work and better than I expected.
> 
> For instance, I believed storing cards as chars would be slower than
> storing them as ints. However, after I implemented COMPACT_STATES I
> discovered that they were much faster than FAST_STATES. (thus changing
> FAST to DEBUG). And now the indirect stack states has become slightly
> faster than compact states after I implemented Copy-On-Write and other
> tricks of not excessively mallocing everything.

Perhaps a better lecture would be "Optimizing C code - tips and tricks"
The tip you've just described would be:
#64 - "Coding is not a religion. Don't believe, measure."

Perhaps if you structure your lecture around such tips, and use fc as an
 example, it would have more value.

The "Wall & Well" paper, was way too scattered to offer any real value 
for me. But then again, I'm probably not your target audiance at all.

> There are some things involved in graphs, but I think they are common
> game AI knowledge. I believe I covered the scans in the 
> lecture, and it is
> mentioned there.

At first I thought I overlooked it, but I think I found 3 sentences that 
are roughly related to it. 
As I said, I believe the application of the algorithms are the interesting 
part, obviously you think the C coding and community building was more
interesting.
Lets agree to disagree here.

> I disagree with you here. Sometimes I had two identical algorithms
> implemented in C that run at drastically different speeds. 
> Like Omer said,
> the devil is in the details. The pseudo-code of Freecell Solver is one
> thing. It can have so many C implementation that it hurts. And the
> difference of speed between each one can be several factors apart.

I agree that the devil is in the details.
However, I don't enjoy discussing the devil. I confront him with all my 
profiling tools when he doesn't leave me a choice, but I prefer to leave 
him alone and purse other interests.

BTW. Do you have pseudo-code for FC? Can you publish it? 
Also, I never really saw your test suit for FC. 
Perhaps you should add a part about testing.
Do you have unit tests? regression? functional tests? 
(I'm not trying to sell mercury products here, I'm really curious).

---

From: Shlomi Fish <[email-masked]>
Date: Tue, 19 Nov 2002 18:13:45 +0200 (IST)

On Tue, 19 Nov 2002, Chen Shapira wrote:

> Perhaps a better lecture wouldbe "Optimizing C code - tips and tricks"

I'd rather give my current lecture as it is. I'm too lazy to write an
altogether different one with the same subject.

> for me. But then again, I'm probably not your target audiance at all.

Perhaps not.

> Lets agree to disagree here.

I agree that we disagree. Albeit there were quite a few
interesting algorithms I used.

> him alone and purse other interests.

I usually leave profiling alone and simply either follow my intuition
(which can be misleading) or try it and then either keep it that way or
revert.

> BTW. Do you have pseudo-code for FC? Can you publish it?

I don't but the pseudo-code would be very simplistic and would not reveal
half of FCS' complexity.

> Also, I never really saw your test suit for FC.

I test it using my own experiments and intuition with tools such as
valgrind, dmalloc and ElectricFence, running it with several boards, etc.
Recently I wrote a perl script to verify the correctness of a Simple Simon
solution, so this is the beginning of a test suite.

I do know for instance that the shared library refuses to compile on IRIX,
and I don't see anything wrong with the autoconfisication or the code. But
IRIX is such a brain-dead system that I don't mind too much.

> Perhaps you should add a part about testing.

To the Arch Doc? Maybe. The problem is that the solution is not guarenteed
to remain the same from version to version.

> (I'm not trying to sell mercury products here, I'm really curious).

I sometimes tested a new module by writing a test function. Sometimes I
trace a bug halfway across gdb, to discover it lies in one certain module.
I don't have too much of a test suite right now, but might be able to add
one with some perl/shell/make hacking.

Many times I released version x.y.0 only then to discover it had a bug and
releasing x.y.1, x.y.2, etc.

Regards,

	Shlomi Fish

>
> To unsubscribe from this group, send an email to:
> [email-masked]
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

----------------------------------------------------------------------
Shlomi Fish        [email-masked]
Home Page:         http://t2.technion.ac.il/~shlomif/
Home E-mail:       [email-masked]

"Let's suppose you have a table with 2^n cups..."
"Wait a second - is n a natural number?"

---

From: Shlomi Fish <[email-masked]>
Date: Tue, 19 Nov 2002 19:19:52 +0200 (IST)

> #64 - "Coding is not a religion. Don't believe, measure."

Which reminds me: Perl 5 recently converted from using QuickSort to using
MergeSort because they claim the latter is faster. It was always believed
a properly optimized (i.e: random + best out of three) quick sort was
faster then MergeSort, but for Perl the opposite is the true.

I once proposed creating a system call to automaticall spawn a child
process from an executable with parameters and new environment. Sort of
like CreateProcess in Win32 or like fork()+execve in one go. Moshe Bar
told me it would not be hard to implement, but that there are complex
models that prove that it only degrades performance. Maybe I should
implement it, and tweak bash, glibc and friends to use it and see if it is
better. <hubris>Maybe those models are false. (!)</hubris>

Regards,

	Shlomi Fish

---

From: Muli Ben-Yehuda <[email-masked]>
Date: Tue, 19 Nov 2002 22:21:50 +0200

> like CreateProcess in Win32 or like fork()+execve in one go. Moshe Bar

What is it good for? 

> models that prove that it only degrades performance. Maybe I should

He didn't happen to mention which models, did he? I didn't think so. 

> better. <hubris>Maybe those models are false. (!)</hubris>

Much more likely, Moshe Bar is wrong. 

The original question stands, though: what is it good for? 
-- 
Muli Ben-Yehuda				    http://www.mulix.org/
[email-masked]:~$ sctrace strace /bin/foo  http://syscalltrack.sf.net/
Quis custodes ipsos custodiet?

---

From: "Nadav Har'El" <[email-masked]>
Date: Tue, 19 Nov 2002 23:14:46 +0200

> models that prove that it only degrades performance. Maybe I should

You brought this idea up on Jan 19th, 2002 on linux-il.

Moshe Bar was not the only one to rain on your parade.
I told you then that if anything, your performance gains will be negligable
because fork's overhead is already very small, and absolutely tiny compared
to other overheads in spawning a new program. I recommended you read the
vfork(2) manual, and also asked

   "I'm not sure why your idea is needed at all. To save a couple of
    microseconds on exec time - when modern programs spends dozens (if not
    thousands - see KDE) of miliseconds on dynamic linking every time you run
    them?"

I consider this another example of a "changing for the sake of making a
change", and not a change coming from a real need. If there's a need, and
a case that could improve from your approach, why don't you start by
demonstrating that need?

Do it if you enjoy it [1], but don't start complaining if your changes don't
make it into the Kernel, claiming that "Linus is a dictator".

[1] I'm the last person to try to stop you from wasting your time on something
    you enjoy. I've been wasting the last several nights burried in stacks
    of Hebrew dictionaries and grammar books just to create my own word list
    (to be published freely, of course) - something that Has Been Done (TM)
    for N times already, and I have no idea if anyone will use once (if?) I
    ever finish it.

-- 
Nadav Har'El                        |     Tuesday, Nov 19 2002, 15 Kislev 5763
[email-masked]             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |If at first you don't succeed, skydiving
http://nadav.harel.org.il           |is not for you.