Red Gnus v0.76 is released

Red Gnus v0.76 is released

[Lars Magne Ingebrigtsen]

Bug fixes.

Get it from <URL:http://www.ifi.uio.no/~larsi/rgnus.tar.gz> or 
"ftp.ifi.uio.no:/pub/emacs/gnus/".

ChangeLog since last release:

Mon Dec 16 23:47:30 1996  Lars Magne Ingebrigtsen  <menja.larsi@ifi.uio.no>

	* gnus.el: Red Gnus v0.76 is released.

Mon Dec 16 14:33:58 1996  Lars Magne Ingebrigtsen  <larsi@ifi.uio.no>

	* gnus-msg.el (gnus-bug): Insert nntp server type.
	(gnus-copy-article-buffer): Remove prev/next buttons.

	* gnus-cache.el (gnus-jog-cache): Let the call func be
	interactive. 

	* gnus-art.el (gnus-summary-save-in-pipe): Include number of
	articles. 
	(gnus-article-add-buttons): Don't add buttons to already
	buttonized areas.

	* nntp.el (nntp-open-connection): Allow `C-g' to continue.

	* nnbabyl.el (nnbabyl-retrieve-headers): Wouldn't find all
	articles sometimes.

	* gnus-sum.el (gnus-data-compute-positions): Reinstated.
	(gnus-remove-thread): Do the right thing with dummy roots.

	* nndoc.el (nndoc-request-article): Only return valid articles.

	* nnfolder.el (nnfolder-delete-mail): Wouldn't delete From lines. 

	* gnus-topic.el (gnus-topic-find-groups): Ignore nil groups. 

	* nnfolder.el (nnfolder-save-mail): Quote all "From " lines.

Sat Dec 14 11:49:21 1996  David Moore  <dmoore@ucsd.edu>

	* gnus-nocem.el (gnus-nocem-groups):
	news.admin.net-abuse.bulletins is to replace
	news.admin.net-abuse.announce for nocemish postings.

Mon Dec 16 13:38:38 1996  Lars Magne Ingebrigtsen  <larsi@ifi.uio.no>

	* nnmail.el (nnmail-move-inbox): Message at end.

	* gnus-sum.el (gnus-summary-refer-parent-article): Use
	"in-reply-to" header.

	* gnus-topic.el (gnus-topic-set-parameters): Enter into dribble. 

	* gnus-sum.el (gnus-summary-save-newsrc): Change.
	(gnus-summary-catchup): Only catch up the limited articles. 
	(gnus-simplify-subject-fuzzy-regexp): Changed to nil.
	(gnus-simplify-buffer-fuzzy): Ignore nil
	gnus-simplify-subject-fuzzy-regexp. 

	* gnus-srvr.el (gnus-server-prepare): Don't insert servers twice.

Thu Dec 12 18:18:11 1996  David Moore  <dmoore@ucsd.edu>

	* gnus-start.el (gnus-setup-news): Use gnus-make-hashtable.
	(gnus-update-active-hashtb-from-killed): ditto.
	(gnus-newsrc-to-gnus-format): ditto.
	
 	* gnus-bcklg.el (gnus-backlog-setup): ditto.

	* gnus-sum.el (gnus-create-xref-hashtb): ditto.

	* gnus-move.el (gnus-move-group-to-server): ditto.

	* gnus-util.el (gnus-create-hash-size): Power of 2 hashtables can
	be _significantly_ faster than 2^x-1 tables on many risc
	machines.  Any gains of 2^x-1 are comparably small on other
	machines. 



-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Red Gnus v0.76 is released

[Jim Meyering]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
| Thu Dec 12 18:18:11 1996  David Moore  <dmoore@ucsd.edu>
| 
| 	* gnus-util.el (gnus-create-hash-size): Power of 2 hashtables can
| 	be _significantly_ faster than 2^x-1 tables on many risc
| 	machines.  Any gains of 2^x-1 are comparably small on other
| 	machines. 

Hi.

Have you considered any other implications of changing the table size
to be a power of 2?  It's pretty generally accepted that hash tables
get better key distributions (fewer collisions) when the table size
is a prime -- or has relatively few factors.  A bad table size (and
powers of 2 are notoriously bad) can make the normally-very-efficient
(O(1)) insert/delete/lookup operations abyssymally slow O(n) ones.

I suspect that choosing table size == 2^N (rather than the
usually-good and sometimes-even-prime 2^N - 1) would degrade the
efficiency due to the increased frequency of collisions.

Whether this matters depends on how full the tables may become.
If they're always nearly empty, then don't worry.  If they ever
contain more than say, 0.6 * table_size elements, I'd start to worry.
In general, if you have the memory, it's best to keep your tables
under 75% full.  That latter is from Knuth.  The 0.6 is my gut
feeling.  The 2^N business is from memory of Knuth and probably
others.

Re: Red Gnus v0.76 is released

[David Moore]

Jim Meyering <meyering@asic.sc.ti.com> writes:

> Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> | Thu Dec 12 18:18:11 1996  David Moore  <dmoore@ucsd.edu>
> | 
> | 	* gnus-util.el (gnus-create-hash-size): Power of 2 hashtables can
> | 	be _significantly_ faster than 2^x-1 tables on many risc
> | 	machines.  Any gains of 2^x-1 are comparably small on other
> | 	machines. 
> 
> Hi.
> 
> Have you considered any other implications of changing the table size
> to be a power of 2?  It's pretty generally accepted that hash tables
> get better key distributions (fewer collisions) when the table size
> is a prime -- or has relatively few factors.  A bad table size (and
> powers of 2 are notoriously bad) can make the normally-very-efficient
> (O(1)) insert/delete/lookup operations abyssymally slow O(n) ones.

	I've looked into this yes, and it's not as large of a problem
with bucket hashs as it is with quadratic rehashing, typically.  With
the ~12,864 newgroups on my site placed in both 16,384 and 16,383 size
hashtable using the xemacs hash function the number, the collision rate
was virtually the same (less than 5% fewer buckets in the power of 2,
although I can't say much about the chain size from lisp).  However, on
the sparc and some other risc processors, over 75% of the cost to
search/insert into the hashtable is in the modulo operation.

> I suspect that choosing table size == 2^N (rather than the
> usually-good and sometimes-even-prime 2^N - 1) would degrade the
> efficiency due to the increased frequency of collisions.

	It tends to depend on your hash function and input data,
although I do usually use a rule of thumb of going to a larger table
when using power of two.  But again it only helps when your hash
function is still doing something reasonable.  I didn't bother doubling
the hashtable size here, because I was mostly after reasonable O(1)
operation, rather than 1 hit accesses.  I didn't think a 128k table in
memory was worth it, since the 64k table was doing fine.

-- 
David Moore <dmoore@ucsd.edu>       | Computer Systems Lab      __o
UCSD Dept. Computer Science - 0114  | Work: (619) 534-8604    _ \<,_
La Jolla, CA 92093-0114             | Fax:  (619) 534-1445   (_)/ (_)
<URL:http://oj.egbt.org/dmoore/>    | In a cloud bones of steel.