Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #386054 > unrolled thread

realloc() - frequency, conditions, or experiences about relocation?

Back to article view | Back to comp.lang.c

Contents

  realloc() - frequency, conditions, or experiences about relocation? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-17 08:08 +0200
    Re: realloc() - frequency, conditions, or experiences about relocation? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-16 23:34 -0700
    Re: realloc() - frequency, conditions, or experiences about relocation? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-17 10:18 +0100
      Re: realloc() - frequency, conditions, or experiences about relocation? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-17 10:31 +0100
        Re: realloc() - frequency, conditions, or experiences about relocation? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-17 10:55 +0100
          Re: realloc() - frequency, conditions, or experiences about relocation? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-17 13:45 +0100
            Re: realloc() - frequency, conditions, or experiences about relocation? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-17 15:33 +0100
              Re: realloc() - frequency, conditions, or experiences about relocation? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-06-17 18:10 +0300
                Re: realloc() - frequency, conditions, or experiences about relocation? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 00:09 -0700
                  Re: realloc() - frequency, conditions, or experiences about relocation? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-18 11:19 +0100
                    Re: realloc() - frequency, conditions, or experiences about relocation? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-18 11:46 +0100
                      Re: realloc() - frequency, conditions, or experiences about relocation? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-29 00:14 +0000
                        Re: realloc() - frequency, conditions, or experiences about relocation? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-07-02 10:18 +0100
                          Re: realloc() - frequency, conditions, or experiences about relocation? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-02 16:39 +0100
                          Re: realloc() - frequency, conditions, or experiences about relocation? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-03 23:48 +0000
                    Re: realloc() - frequency, conditions, or experiences about relocation? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-24 09:32 -0700
                      Re: realloc() - frequency, conditions, or experiences about relocation? David Brown <david.brown@hesbynett.no> - 2024-06-24 19:19 +0200
                  Indefinite pronouns [was:Re: realloc() - frequency, conditions, or experiences about relocation?] Anton Shepelev <anton.txt@gmail.moc> - 2024-06-20 02:51 +0300
                    Re: Indefinite pronouns vallor <vallor@cultnix.org> - 2024-06-20 00:34 +0000
                      Re: Indefinite pronouns David Brown <david.brown@hesbynett.no> - 2024-06-21 12:59 +0200
                        Re: Indefinite pronouns Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-21 10:31 -0700
                    Re: Indefinite pronouns [was:Re: realloc() - frequency, conditions, or experiences about relocation?] gazelle@shell.xmission.com (Kenny McCormack) - 2024-06-20 12:10 +0000
                      Re: Indefinite pronouns [was: Re: <something technical>] Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-20 15:04 +0200
                    Re: Indefinite pronouns [was:Re: realloc() - frequency, conditions, or experiences about relocation?] Cri-Cri <cri@cri.cri.invalid> - 2024-06-21 00:55 +0000
                    Re: Indefinite pronouns [was:Re: realloc() - frequency, conditions, or experiences about relocation?] Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-20 23:23 -0700
              Re: realloc() - frequency, conditions, or experiences about relocation? Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-17 16:15 +0100
                Re: realloc() - frequency, conditions, or experiences about relocation? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-17 13:05 -0700
              Re: realloc() - frequency, conditions, or experiences about relocation? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-17 16:36 +0100
            Re: realloc() - frequency, conditions, or experiences about relocation? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-06-17 18:02 +0300
              Re: realloc() - frequency, conditions, or experiences about relocation? "David Jones" <dajhawk18xx@@nowhere.com> - 2024-06-18 17:59 +0000
              Re: realloc() - frequency, conditions, or experiences about relocation? davidd02@tpg.com.au (David Duffy) - 2024-06-19 06:48 +0000
                Re: realloc() - frequency, conditions, or experiences about relocation? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-19 10:12 +0100
                  Re: realloc() - frequency, conditions, or experiences about relocation? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-19 16:36 +0100
                    Re: realloc() - frequency, conditions, or experiences about relocation? David Brown <david.brown@hesbynett.no> - 2024-06-19 19:41 +0200
                      Re: realloc() - frequency, conditions, or experiences about relocation? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-19 22:24 +0100
                        Re: realloc() - frequency, conditions, or experiences about relocation? David Brown <david.brown@hesbynett.no> - 2024-06-20 13:22 +0200
                  Re: realloc() - frequency, conditions, or experiences about relocation? Anton Shepelev <anton.txt@gmail.moc> - 2024-06-20 01:53 +0300
                    Re: realloc() - frequency, conditions, or experiences about relocation? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-07-08 19:34 +0300
                Re: realloc() - frequency, conditions, or experiences about relocation? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-06-19 15:20 +0300
              Re: realloc() - frequency, conditions, or experiences about relocation? Rich Ulrich <rich.ulrich@comcast.net> - 2024-07-02 00:51 -0400
                Re: realloc() - frequency, conditions, or experiences about relocation? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-01 22:10 -0700
                  Re: realloc() - frequency, conditions, or experiences about relocation? Rich Ulrich <rich.ulrich@comcast.net> - 2024-07-02 11:45 -0400
                    Re: realloc() - frequency, conditions, or experiences about relocation? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-07-08 20:01 +0300
                      Re: realloc() - frequency, conditions, or experiences about relocation? Rich Ulrich <rich.ulrich@comcast.net> - 2024-07-21 19:40 -0400
                        Re: realloc() - frequency, conditions, or experiences about relocation? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-07-23 16:47 +0300
                Re: realloc() - frequency, conditions, or experiences about relocation? Paul <nospam@needed.invalid> - 2024-07-02 03:02 -0400
                  Re: realloc() - frequency, conditions, or experiences about relocation? Rich Ulrich <rich.ulrich@comcast.net> - 2024-07-02 11:52 -0400
                    Re: realloc() - frequency, conditions, or experiences about relocation? Rich Ulrich <rich.ulrich@comcast.net> - 2024-07-02 11:58 -0400
                      Re: realloc() - frequency, conditions, or experiences about relocation? Paul <nospam@needed.invalid> - 2024-07-02 15:09 -0400
                        Re: realloc() - frequency, conditions, or experiences about relocation? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-02 16:54 -0400
                        Re: realloc() - frequency, conditions, or experiences about relocation? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-02 16:58 -0400
            Re: realloc() - frequency, conditions, or experiences about relocation? scott@slp53.sl.home (Scott Lurndal) - 2024-06-17 16:58 +0000
              Re: realloc() - frequency, conditions, or experiences about relocation? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-17 13:12 -0700
            Re: realloc() - frequency, conditions, or experiences about relocation? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-17 16:39 -0700
              Re: realloc() - frequency, conditions, or experiences about relocation? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-18 06:12 +0100
              Re: realloc() - frequency, conditions, or experiences about relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-18 09:56 +0200
        Re: realloc() - frequency, conditions, or experiences about relocation? David Brown <david.brown@hesbynett.no> - 2024-06-17 20:11 +0200
    Re: realloc() - frequency, conditions, or experiences about relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-17 11:22 +0200
      Re: realloc() - frequency, conditions, or experiences about relocation? Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-20 21:08 +0100
        Re: realloc() - frequency, conditions, or experiences about relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-21 21:12 +0200
          Re: realloc() - frequency, conditions, or experiences about relocation? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-24 08:40 +0000
            Re: realloc() - frequency, conditions, or experiences about relocation? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-24 02:55 -0700
              Re: realloc() - frequency, conditions, or experiences about relocation? David Brown <david.brown@hesbynett.no> - 2024-06-24 13:40 +0200
                Re: realloc() - frequency, conditions, or experiences about relocation? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-24 18:50 +0100
                  Re: realloc() - frequency, conditions, or experiences about relocation? scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 18:20 +0000
                    Re: realloc() - frequency, conditions, or experiences about relocation? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-24 14:28 -0700
                      Re: realloc() - frequency, conditions, or experiences about relocation? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-25 00:22 +0100
                      Re: realloc() - frequency, conditions, or experiences about relocation? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-24 18:31 -0700
                  Re: realloc() - frequency, conditions, or experiences about relocation? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-25 07:06 +0000
                    Re: realloc() - frequency, conditions, or experiences about relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-25 10:38 +0200
                      Re: realloc() - frequency, conditions, or experiences about relocation? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-26 00:51 +0000
                Re: realloc() - frequency, conditions, or experiences about relocation? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-24 12:33 -0700
                  Re: realloc() - frequency, conditions, or experiences about relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-24 21:48 +0200
                Re: realloc() - frequency, conditions, or experiences about relocation? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-24 22:59 +0000
              Re: realloc() - frequency, conditions, or experiences about relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-24 16:19 +0200
              Re: realloc() - frequency, conditions, or experiences about relocation? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-25 07:02 +0000
                Re: realloc() - frequency, conditions, or experiences about relocation? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-25 03:05 -0700
                  Re: realloc() - frequency, conditions, or experiences about relocation? Richard Damon <richard@damon-family.org> - 2024-06-25 07:21 -0400
                  Re: realloc() - frequency, conditions, or experiences about relocation? Phil Carmody <pc+usenet@asdf.org> - 2024-06-28 11:01 +0300
                    Re: realloc() - frequency, conditions, or experiences about relocation? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-28 04:04 -0700
                  Re: realloc() - frequency, conditions, or experiences about relocation? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-28 06:37 -0400
                    Re: realloc() - frequency, conditions, or experiences about relocation? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-28 04:05 -0700
                Re: realloc() - frequency, conditions, or experiences about relocation? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-28 06:36 -0400
            Re: realloc() - frequency, conditions, or experiences about relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-24 16:16 +0200
              Down the hall, past the water cooler, third door on the left... (Was: realloc() - frequency, conditions, or experiences about) relocation? gazelle@shell.xmission.com (Kenny McCormack) - 2024-06-24 15:44 +0000
                Re: Down the hall, past the water cooler, third door on the left... (Was: realloc() - frequency, conditions, or experiences about) relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-24 20:16 +0200
    Re: realloc() - frequency, conditions, or experiences about relocation? David Brown <david.brown@hesbynett.no> - 2024-06-17 14:15 +0200
      Re: realloc() - frequency, conditions, or experiences about relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-17 14:18 +0200
    Re: realloc() - frequency, conditions, or experiences about relocation? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-17 15:21 +0200
    Re: realloc() - frequency, conditions, or experiences about relocation? scott@slp53.sl.home (Scott Lurndal) - 2024-06-17 16:50 +0000
      Re: realloc() - frequency, conditions, or experiences about relocation? Michael S <already5chosen@yahoo.com> - 2024-06-17 20:20 +0300
        Re: realloc() - frequency, conditions, or experiences about relocation? scott@slp53.sl.home (Scott Lurndal) - 2024-06-17 19:02 +0000
    Re: realloc() - frequency, conditions, or experiences about relocation? Rosario19 <Ros@invalid.invalid> - 2024-06-18 11:50 +0200
    Re: realloc() - frequency, conditions, or experiences about relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-25 10:48 +0200
      Re: realloc() - frequency, conditions, or experiences about relocation? Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-25 11:55 +0100
        Re: realloc() - frequency, conditions, or experiences about relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-25 13:28 +0200
          Re: realloc() - frequency, conditions, or experiences about relocation? Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-26 12:15 +0100
            Re: realloc() - frequency, conditions, or experiences about relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-26 15:01 +0200
      Re: realloc() - frequency, conditions, or experiences about relocation? DFS <nospam@dfs.com> - 2024-06-25 09:56 -0400
        Re: realloc() - frequency, conditions, or experiences about relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-25 16:16 +0200

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#386695

Rich Ulrich <rich.ulrich@comcast.net> writes:
> On Mon, 17 Jun 2024 18:02:49 +0300, Anton Shepelev
> <anton.txt@g{oogle}mail.com> wrote:
>
>>[cross-posted to: ci.stat.math]
>>
> Anton, 
>
> The post being responded to was originally to comp.lang.c
> which I don't subscribe to. 
>
> I have a question that I suppose reflects on my news source, 
> GigaNews, or else on my reader, Forte Agent. 
>
> Was this thread something posted 15 or 20 years ago? 
>
> I tried to call up the original post by clicking on the Message
> ID when looking at headers; nothing comes up when Agent goes
> online to look.  The header shows multiple earlier messages; 
> none of them come up for me. 
>
> My clicking on Message ID works elsewhere. The logical and 
> simple explanation is that this is a thread old enough that
> GigaNews does not have it. 
>
> I suppose that someone else might be able to tell me, if their 
> supplier goes back further or if GigaNews is somehow failing
> to show me something that is recent. 

The first article in this thread was posted to comp.lang.c by Janis
Papanagnou on 17 Jun 2024.

There were several followups on the same day.  The diret parent of your
article was cross-posted to comp.lang.c and sci.stat.math by Anton
Shepelev (his was the first cross-posted article in the thread).

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#386714

On Mon, 01 Jul 2024 22:10:00 -0700, Keith Thompson
<Keith.S.Thompson+u@gmail.com> wrote:

>Rich Ulrich <rich.ulrich@comcast.net> writes:
>> On Mon, 17 Jun 2024 18:02:49 +0300, Anton Shepelev
>> <anton.txt@g{oogle}mail.com> wrote:
>>
>>>[cross-posted to: ci.stat.math]
>>>
>> Anton, 
>>
>> The post being responded to was originally to comp.lang.c
>> which I don't subscribe to. 
>>
>> I have a question that I suppose reflects on my news source, 
>> GigaNews, or else on my reader, Forte Agent. 
>>
>> Was this thread something posted 15 or 20 years ago? 
>>
>> I tried to call up the original post by clicking on the Message
>> ID when looking at headers; nothing comes up when Agent goes
>> online to look.  The header shows multiple earlier messages; 
>> none of them come up for me. 
>>
>> My clicking on Message ID works elsewhere. The logical and 
>> simple explanation is that this is a thread old enough that
>> GigaNews does not have it. 
>>
>> I suppose that someone else might be able to tell me, if their 
>> supplier goes back further or if GigaNews is somehow failing
>> to show me something that is recent. 
>
>The first article in this thread was posted to comp.lang.c by Janis
>Papanagnou on 17 Jun 2024.
>
>There were several followups on the same day.  The diret parent of your
>article was cross-posted to comp.lang.c and sci.stat.math by Anton
>Shepelev (his was the first cross-posted article in the thread).

Thanks, so it looks like a failure by GigaNews to retrieve the
recent posts. 

I did see a bunch of cross-posted followups. I don't know C, 
and I thought there could be more context. 

Looking at original, absent posts is something I've done dozens 
of times over the years.  Never a problem, except fora time or two 
with posts from the 1990s.  I've used GigaNews since my regular
ISP stopped providing Usenet access, maybe 15 years ago. 

-- 
Rich Ulrich 

[toc] | [prev] | [next] | [standalone]

#386890

Rich Ulrich:

> Thanks, so it looks like a failure by GigaNews to retrieve
> the recent posts.
>
> I did see a bunch of cross-posted followups. I don't know
> C, and I thought there could be more context.

Characters are being read in (say, from a file) sequentially
and stored in computer memory (RAM) in an "array" -- a
linear data structure storing elements (our characters) in a
sequential order, one ofter the other at addresses with
increasing indexes -- somewhat like a mathematical vector.

In order to store a character in an array, sufficient memory
has to be "allocated" for it, but while reading we do not
know beforehand the size of the file (or the total length of
the sequence), and therefore increase the allocated aray
size prospectively once the previous allocation is filled.
This operaion is called `realloc' and frequently involves
the tedious copying of the entire array onto a new location
in memory, taking a time in proportion to the number
elemennts so far allocated.

The question is to develop an optimal allcation strategy for
a given distribution of file sizes.  The fasted solution is
to allocate a gigantic array beforehand, but it is a
terrible waste of memory.  The slowet solution is to
reallcoate for each single character read it, but is a
terrible waste of CPU time.  As I understand the problem, a
strategy is needed that manifests some compromise between
the extremes.

> Looking at original, absent posts is something I've done
> dozens of times over the years.  Never a problem, except
> fora time or two with posts from the 1990s.  I've used
> GigaNews since my regular ISP stopped providing Usenet
> access, maybe 15 years ago.

Just in case, there are many totally free Usenet servers,
e.g.:
             http://www.eternal-september.org/
             https://www.i2pn2.org/

and even a web interface:

             https://www.novabbs.com

-- 
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments

[toc] | [prev] | [next] | [standalone]

#387216

On Mon, 8 Jul 2024 20:01:21 +0300, Anton Shepelev
<anton.txt@g{oogle}mail.com> wrote:

>Rich Ulrich:
>
>> Thanks, so it looks like a failure by GigaNews to retrieve
>> the recent posts.
>>
>> I did see a bunch of cross-posted followups. I don't know
>> C, and I thought there could be more context.

<snip.  Thanks for the details.>

Okay, today I discovered that there was no failure by Giganews
or by Forte Agent -- Instead, there was BEHAVIOR by Agent 
that I was not aware of. 

Today, was looking at All Desks (Agent terminology) to see what
was in Sent, and I noticed there were messages in Inbox -- Those 
were the messages that I thought Agent had failed to retrieve. 
(Nice discussion there.)

I guess - every other time I've clicked on Message-ID, the old
message was in the group where I was reading and the old one
showed up where I was reading. I've read the Agent group for
ages, and I don't remember this feature ever being mentioned. 

Live and learn.

-- 
Rich Ulrich 

[toc] | [prev] | [next] | [standalone]

#387217

Rich Ulrich:

> Today, was looking at All Desks (Agent terminology) to see
> what was in Sent, and I noticed there were messages in
> Inbox -- Those were the messages that I thought Agent had
> failed to retrieve.  (Nice discussion there.)

Looking forward to your take on the problem.  Mine is rather
simplisitc, but can be easily tested with several
distributions. This is like extrapolation: we know the
optimal solution for the given distribution (exponential)
and want to devise a general method to get the optimal
solution for any given distribution.

Malcolm, if you are still interested, can you provide a test
program that measures some statiscits for various allocation
strategies on various distributions, inclusing the
exponential?

-- 
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments

[toc] | [prev] | [next] | [standalone]

#386696

On 7/2/2024 12:51 AM, Rich Ulrich wrote:
> On Mon, 17 Jun 2024 18:02:49 +0300, Anton Shepelev
> <anton.txt@g{oogle}mail.com> wrote:
> 
>> [cross-posted to: ci.stat.math]
>>
> Anton, 
> 
> The post being responded to was originally to comp.lang.c
> which I don't subscribe to. 
> 
> I have a question that I suppose reflects on my news source, 
> GigaNews, or else on my reader, Forte Agent. 
> 
> Was this thread something posted 15 or 20 years ago? 
> 
> I tried to call up the original post by clicking on the Message
> ID when looking at headers; nothing comes up when Agent goes
> online to look.  The header shows multiple earlier messages; 
> none of them come up for me. 
> 
> My clicking on Message ID works elsewhere. The logical and 
> simple explanation is that this is a thread old enough that
> GigaNews does not have it. 
> 
> I suppose that someone else might be able to tell me, if their 
> supplier goes back further or if GigaNews is somehow failing
> to show me something that is recent. 
> 

MID:   <v4ojs8$gvji$1@dont-email.me>

http://al.howardknight.net/

That gives this URL, as a copy of the message kicking off the thread.

   http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4ojs8%24gvji%241%40dont-email.me%3E

Some USENET News clients can work from the MID directly, but Thunderbird does not.
A bare MID does not work for everyone.

   Paul

[toc] | [prev] | [next] | [standalone]

#386716

On Tue, 2 Jul 2024 03:02:07 -0400, Paul <nospam@needed.invalid> wrote:

>On 7/2/2024 12:51 AM, Rich Ulrich wrote:
>> On Mon, 17 Jun 2024 18:02:49 +0300, Anton Shepelev
>> <anton.txt@g{oogle}mail.com> wrote:
>> 
>>> [cross-posted to: ci.stat.math]
>>>
>> Anton, 
>> 
>> The post being responded to was originally to comp.lang.c
>> which I don't subscribe to. 
>> 
>> I have a question that I suppose reflects on my news source, 
>> GigaNews, or else on my reader, Forte Agent. 
>> 
>> Was this thread something posted 15 or 20 years ago? 
>> 
>> I tried to call up the original post by clicking on the Message
>> ID when looking at headers; nothing comes up when Agent goes
>> online to look.  The header shows multiple earlier messages; 
>> none of them come up for me. 
>> 
>> My clicking on Message ID works elsewhere. The logical and 
>> simple explanation is that this is a thread old enough that
>> GigaNews does not have it. 
>> 
>> I suppose that someone else might be able to tell me, if their 
>> supplier goes back further or if GigaNews is somehow failing
>> to show me something that is recent. 
>> 
>
>MID:   <v4ojs8$gvji$1@dont-email.me>
>
>http://al.howardknight.net/
>
>That gives this URL, as a copy of the message kicking off the thread.
>
>   http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4ojs8%24gvji%241%40dont-email.me%3E
>

Yes, that's the message I see when I plug the Message ID
into the program at  http://al.howardknight.net/

Thanks.  I'm saving that. 


>Some USENET News clients can work from the MID directly, but Thunderbird does not.
>A bare MID does not work for everyone.

Forte Agent invites me to click on the MID; asks if it is a 
mail or MID; asks if it should search the net.  It still works
when I test it on an old message in another group. 

-- 
Rich Ulrich

[toc] | [prev] | [next] | [standalone]

#386717

On Tue, 02 Jul 2024 11:52:56 -0400, Rich Ulrich
<rich.ulrich@comcast.net> wrote:

>
>Forte Agent invites me to click on the MID; asks if it is a 
>mail or MID; asks if it should search the net.  It still works
>when I test it on an old message in another group. 
>

Now it occurs to me -- It actually does make sense, 
economically, if what is searched online is limited the 
groups I subscribe to, or (even) only the group that
is currently active. 

-- 
Rich Ulrich 

[toc] | [prev] | [next] | [standalone]

#386720

On 7/2/2024 11:58 AM, Rich Ulrich wrote:
> On Tue, 02 Jul 2024 11:52:56 -0400, Rich Ulrich
> <rich.ulrich@comcast.net> wrote:
> 
>>
>> Forte Agent invites me to click on the MID; asks if it is a 
>> mail or MID; asks if it should search the net.  It still works
>> when I test it on an old message in another group. 
>>
> 
> Now it occurs to me -- It actually does make sense, 
> economically, if what is searched online is limited the 
> groups I subscribe to, or (even) only the group that
> is currently active. 
> 

Every device has "retention", but retention is limited.

Whether it's a search site, or a USENET server (even Forte had
their own news server, at one time), you need retention for
older articles to be search-able either as body text, or as
a <mid>.

Now that Google Groups is no longer connected to USENET,
that's one fewer places with a decent-sized archive. Google closed
their service, after the ThaiSpam incident. The Eternal-September
server, changed from one server to a two-server setup. The
Transit Server had Spam Assassin loaded on it, removing THaiSpam,
and the second server continued to offer normal ("filtered") service.

The comp.lang.c group was one of the groups under attack. Since
Google was letting the spam in, now that Google is disconnected,
the spam is gone, and the readership on CLC has gone up.

   Paul

[toc] | [prev] | [next] | [standalone]

#386724

On 7/2/24 15:09, Paul wrote:
...
> Now that Google Groups is no longer connected to USENET,

I just checked, and as I had expected, Google is still connected.

> that's one fewer places with a decent-sized archive. Google closed
> their service, after the ThaiSpam incident.

They didn't close their service. They just stopped adding new messages
to their archives. The messages that were stored prior to the closing
are still available for searching.

[toc] | [prev] | [next] | [standalone]

#386725

On 7/2/24 15:09, Paul wrote:
...
> Now that Google Groups is no longer connected to USENET,
...
> that's one fewer places with a decent-sized archive. Google closed
> their service, after the ThaiSpam incident.

While they no longer store new messages, they still have one of the
largest archives of old messages, and it's still available for searching.

[toc] | [prev] | [next] | [standalone]

#386111

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On 17/06/2024 10:55, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> 

>> 
>> I have no idea what you are talking about.  What "value" are you looking
>> to calculate?
>> 
>We have a continuously growing buffer, 

At this point, you should be asking yourself
if there are better alternatives for storing
the incoming data than to a continuously growing
dynamically allocated piecemeal  buffer.

C character stdio tends to work well for streaming applications
(i.e. pipelines where the input is (minimally) processed and forwarded
to the output), but not so efficiently for applications that need to
look at the data en masse.

Personnally, I'd mmap the input file and eschew stdio completely
and just walk through memory with the appropriate pointer.

(mmap showed up in the late 80s, so you can pretend it
is C90 if you like).

[toc] | [prev] | [next] | [standalone]

#386119

On 6/17/2024 9:58 AM, Scott Lurndal wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On 17/06/2024 10:55, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>
> 
>>>
>>> I have no idea what you are talking about.  What "value" are you looking
>>> to calculate?
>>>
>> We have a continuously growing buffer,
> 
> At this point, you should be asking yourself
> if there are better alternatives for storing
> the incoming data than to a continuously growing
> dynamically allocated piecemeal  buffer.
> 
> C character stdio tends to work well for streaming applications
> (i.e. pipelines where the input is (minimally) processed and forwarded
> to the output), but not so efficiently for applications that need to
> look at the data en masse.

Indeed.


> Personnally, I'd mmap the input file and eschew stdio completely
> and just walk through memory with the appropriate pointer.

That works for sure. Actually, its been a while since I have used memory 
mapped files. I made a little database thing with them that multiple 
processes could use, lock-free... ;^)

Also, I remember a nifty trick to use memory mapped files with certain 
lock-free algorithms. I need to find that old post over on 
comp.programming.threads. Have a feeling that its going to be hard to find!


> (mmap showed up in the late 80s, so you can pretend it
> is C90 if you like).

[toc] | [prev] | [next] | [standalone]

#386129

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> We have a continuously growing buffer, and we want the best strategy
> for reallocations as the stream of characters comes at us. So, given
> we now how many characters have arrived, can we predict how many will
> arrive, and therefore ask for the best amount when we reallocate, so
> that we neither make too many reallocation (reallocate on every byte
> received) or ask for too much (demand SIZE_MAX memory when the first
> byte is received).?
[...]

That's going to depend on the behavior of the implementations
realloc() function.

malloc() and realloc() typically allocate more memory than they're
asked for, so that another realloc() call can often expand the
allocated memory in place.

I have a small test program that uses realloc() to expand a 1-byte
allocated buffer to 2 bytes, then 3, then 4, and so on.  In one
implementation, in one test run, it reallocates at 25 bytes, and
then not again until just over 128 kbytes.  Other implementations
behave differently.

A realloc() call that's able to return its first argument is likely
to be much quicker than one that does an actual reallocation.
If you want to fine tune for performance, you'll have to allow
for the implementation you're using, either by performing run-time
measurements or by analyzing the implementation (which could change
in the next release).

Multiplying the size by 2 or 1.5 as needed is likely to be good enough.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#386138

On 18/06/2024 00:39, Keith Thompson wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> [...]
>> We have a continuously growing buffer, and we want the best strategy
>> for reallocations as the stream of characters comes at us. So, given
>> we now how many characters have arrived, can we predict how many will
>> arrive, and therefore ask for the best amount when we reallocate, so
>> that we neither make too many reallocation (reallocate on every byte
>> received) or ask for too much (demand SIZE_MAX memory when the first
>> byte is received).?
> [...]
> 
> That's going to depend on the behavior of the implementations
> realloc() function.
> 
> malloc() and realloc() typically allocate more memory than they're
> asked for, so that another realloc() call can often expand the
> allocated memory in place.
> 
> I have a small test program that uses realloc() to expand a 1-byte
> allocated buffer to 2 bytes, then 3, then 4, and so on.  In one
> implementation, in one test run, it reallocates at 25 bytes, and
> then not again until just over 128 kbytes.  Other implementations
> behave differently.
> 
> A realloc() call that's able to return its first argument is likely
> to be much quicker than one that does an actual reallocation.
> If you want to fine tune for performance, you'll have to allow
> for the implementation you're using, either by performing run-time
> measurements or by analyzing the implementation (which could change
> in the next release).
> 
> Multiplying the size by 2 or 1.5 as needed is likely to be good enough.
> 
A small test program can hog all of memory for itself, and so isn't a 
good test. What matters is where you're running something like a video 
game, and the artists stuff the comupter's memory full of artwork until 
it runs out, and then slowly and reluctantly remove their masterworks 
until the other routines have enough memory to run. So the game won't 
run out of memory, but only just. It's very tight.

-- 
Check out my hobby project.
http://malcolmmclean.github.io/babyxrc

[toc] | [prev] | [next] | [standalone]

#386152

Am 18.06.2024 um 01:39 schrieb Keith Thompson:

> I have a small test program that uses realloc() to expand a 1-byte
> allocated buffer to 2 bytes, then 3, then 4, and so on.  In one
> implementation, in one test run, it reallocates at 25 bytes, and
> then not again until just over 128 kbytes.  Other implementations
> behave differently.

Usually you don't expand a dynamic array byte per byte. Normaly you
expand it like a C++ vector whose capacity doubles with libstdc++
and libc++ (MSVC adds 50% to the capacity before).

[toc] | [prev] | [next] | [standalone]

#386113

On 17/06/2024 11:31, Malcolm McLean wrote:
> On 17/06/2024 10:18, Ben Bacarisse wrote:
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>
>>> In a recent thread realloc() was a substantial part of the discussion.
>>> "Occasionally" the increased data storage will be relocated along
>>> with the previously stored data. On huge data sets that might be a
>>> performance factor. Is there any experience or are there any concrete
>>> factors about the conditions when this relocation happens? - I could
>>> imagine that it's no issue as long as you're in some kB buffer range,
>>> but if, say, we're using realloc() to substantially increase buffers
>>> often it might be an issue to consider. It would be good to get some
>>> feeling about that internal.
>>
>> There is obviously a cost, but there is (usually) no alternative if
>> contiguous storage is required.  In practice, the cost is usually
>> moderate and can be very effectively managed by using an exponential
>> allocation scheme: at every reallocation multiply the storage space by
>> some factor greater than 1 (I often use 3/2, but doubling is often used
>> as well).  This results in O(log(N)) rather than O(N) allocations as in
>> your code that added a constant to the size.  Of course, some storage is
>> wasted (that /might/ be retrieved by a final realloc down to the final
>> size) but that's rarely significant.
>>
> So can we work it out?
> 
> Let's assume for the moment that the allocations have a semi-normal 
> distribution, with negative values disallowed. Now ignoring the first 
> few values, if we have allocated, say, 1K, we ought to be able to 
> predict the value by integrating the distribution from 1k to infinity 
> and taking the mean.
> 

First, there is no reason for assuming such a distribution, other than 
saying "lots of things are roughly normal".

Secondly, knowing the distribution gives you /no/ information about any 
given particular case.  You know the distribution for the results of 
rolling two die - does that mean you can predict the next roll?

Thirdly, not all distributions have a mean (look up the Cauchy 
distribution if you like).

Fourthly, even if you know the mean, it tells you nothing of use.


Knowing a bit about the distribution of file sizes can be useful, but 
not nearly in the way you describe here.  If you know that the files are 
rarely or never bigger than 10 MB, malloc 10 MB and forget the realloc. 
If you know they are often bigger than that, mmap the file and forget 
the realloc.

[toc] | [prev] | [next] | [standalone]

#386071

Am 17.06.2024 um 08:08 schrieb Janis Papanagnou:
> In a recent thread realloc() was a substantial part of the discussion.
> "Occasionally" the increased data storage will be relocated along
> with the previously stored data. On huge data sets that might be a
> performance factor. Is there any experience or are there any concrete
> factors about the conditions when this relocation happens? - I could
> imagine that it's no issue as long as you're in some kB buffer range,
> but if, say, we're using realloc() to substantially increase buffers
> often it might be an issue to consider. It would be good to get some
> feeling about that internal.
> 
> Janis

realloc() is just a convenience funciton. Usually the reallocation
can't happen in-place and a second malloc() followed by a copy and
a free() does the same.
For large data it would be nice if the pages being deallocated later
would be incrementally marked as discardable after copying a portion.
This would result in only a small portion of additional physical
memory being allocated since the newly allocated pages become asso-
ciated with phyiscal pages when they're touched first. Windows has
VirtualAlloc() with MEM_RESET for that, Linux has madvise() with
MADV_DONTNEED.

[toc] | [prev] | [next] | [standalone]

#386281

On 17/06/2024 10:22, Bonita Montero wrote:
> 
> realloc() is just a convenience funciton. Usually the reallocation
> can't happen in-place and a second malloc() followed by a copy and
> a free() does the same.
> For large data it would be nice if the pages being deallocated later
> would be incrementally marked as discardable after copying a portion.
> This would result in only a small portion of additional physical
> memory being allocated since the newly allocated pages become asso-
> ciated with phyiscal pages when they're touched first. Windows has
> VirtualAlloc() with MEM_RESET for that, Linux has madvise() with
> MADV_DONTNEED.

"Usually can't happen in place"?

Really? It's not something I use a lot, but when it's appropriate I 
will. It's got the advantage over doing this myself that for some 
portion of calls all the run time library needs to do is change the size 
field in the structure.

Nothing else.

No copying, and no duplicate allocations.

What proportion of calls can be managed by changing the size field alone 
depends on your workload and the platform. But I doubt there are many 
cases where it is 0%.

Andy

[toc] | [prev] | [next] | [standalone]

#386331

Am 20.06.2024 um 22:08 schrieb Vir Campestris:
> On 17/06/2024 10:22, Bonita Montero wrote:
>>
>> realloc() is just a convenience funciton. Usually the reallocation
>> can't happen in-place and a second malloc() followed by a copy and
>> a free() does the same.
>> For large data it would be nice if the pages being deallocated later
>> would be incrementally marked as discardable after copying a portion.
>> This would result in only a small portion of additional physical
>> memory being allocated since the newly allocated pages become asso-
>> ciated with phyiscal pages when they're touched first. Windows has
>> VirtualAlloc() with MEM_RESET for that, Linux has madvise() with
>> MADV_DONTNEED.
> 
> "Usually can't happen in place"?

Usually you don't resize the block with a few bytes and if you have
a large memory area it's unlikely that you can allocate a few additional
pages in-place.
C++23 has a nice function with the allocator interface called allocate
_at_least. It returns the pointer to the allocated memory with the size
actually allocated. This fits with modern allocators like mimalloc, je-
malloc or tcmalloc, which round up the allocation to the next 2 ^ N
boundary up to 8kB. So a vector's capacity directly includes the blend.

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web