adj
At 9:30 PM +0200 10/1/03, Paul Courbis wrote:
Unfortunately your download link gives :
Not Found
The requested URL /coreutils-4.5.3-alexa03.tar.gz was not found on this server.
--------------------------------------------------------------------------------
Apache/1.3.26 Server at alexautils.sourceforge.net Port 80
:-(
Regards
Paul
On Wed, Oct 01, 2003 at 12:59:10PM -0400, Andrew D Jewell wrote:You can get our version of coreutils 4.5.3 from http://alexautils.sourceforge.net/
We've had good results with NMERGE up around 1000
The merge code in standard sort is O(NMERGE * total_lines) which is already bad at 16 and terrible if you get much higher. The alexautils code has different merging code which is O(log(NMERGE) * total_lines) which works great.
adj
At 12:57 PM +0200 9/30/03, Paul Courbis wrote: >Hi > >I'm using "sort" to, surprisingly, sort huge files (up to 2 GB). Of >course I had to use the -S switch to tune memory usage. My concern >is that I >don't have enough memory to sort in RAM, thus sort is using >temporary files tat it merges to get the final result. > >Having a look to sort's sources I noticed that NMERGE is hardocoded >(it's not even an option). > >My questions are : > >- I did a patch to make sort accept a new option (currently called >-N to setup NMERGE). Is someone interested by this patch ? >- I'm doing some benches, but I already noticed that 16 (the >hardcoded value) is not always the best one. For example my first >serie of benches showed me that 18 is better in this particular >case. Did someone worked on a model allowing to guess what would be >the best value for NMERGE for a given set of data to sort ? > >Any hint would be apreciated > >regards > >Paul > > > >_______________________________________________ >Bug-coreutils mailing list >[EMAIL PROTECTED] >http://mail.gnu.org/mailman/listinfo/bug-coreutils
_______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
