Regarding calculation of free memory
CASTalk.com Forum Index CASTalk.com
Discussion of DSP, FPGA, storage and embedded system.
 
 FAQFAQ   MemberlistMemberlist     RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
 
Google
 
Web castalk.com
Regarding calculation of free memory
Goto page Previous  1, 2, 3, 4, 5
 
Post new topic   Reply to topic    CASTalk.com Forum Index -> Computer Architecture
Author Message
Guest
Posted: Wed Oct 05, 2005 4:15 pm    Post subject: Re: Regarding calculation of free memory Reply with quote
"FredK" <fred.nospam@nospam.dec.com> writes:
Quote:
"Casper H.S. Dik" <Casper.Dik@Sun.COM> wrote in message
That's not just an issue with case sensitivity but a similar
situations can arise with other naming schemes. (And this
one source of confusion is easily recmoved using a coding
style which specifies how to use case.


I've yet to find UNIX code that sticks to a convention, and that is
remotely safe from boneheaded mistakes. Probably 80% or more
of the code I've seen doesn't use C prototypes, which would
have at least pointed out they wanted Delete() instead of delete() -
each of which had different parameters (for an example).

I'm curious where such code comes from - can you say? Most (nearly all?) of
the code I see, i.e., mostly open source code, has prototypes.

--
David Gay
dgay@acm.org
Back to top
Nick Maclaren
Guest
Posted: Wed Oct 05, 2005 9:29 pm    Post subject: Re: Regarding calculation of free memory Reply with quote
In article <79oe64as21.fsf@barnowl.research.intel-research.net>,
dgay@barnowl.research.intel-research.net writes:
|> "FredK" <fred.nospam@nospam.dec.com> writes:
|> >
|> > I've yet to find UNIX code that sticks to a convention, and that is
|> > remotely safe from boneheaded mistakes. Probably 80% or more
|> > of the code I've seen doesn't use C prototypes, which would
|> > have at least pointed out they wanted Delete() instead of delete() -
|> > each of which had different parameters (for an example).
|>
|> I'm curious where such code comes from - can you say? Most (nearly all?) of
|> the code I see, i.e., mostly open source code, has prototypes.

Older code, mainly. Most open source code has been using ISO C
(or what it thinks is ISO C) for only 5-10 years - before 1995,
there were a LOT of systems which didn't have an even remotely
conforming compiler.


Regards,
Nick Maclaren.
Back to top
Guest
Posted: Wed Oct 05, 2005 9:51 pm    Post subject: Re: Regarding calculation of free memory Reply with quote
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:

Quote:
In article <79oe64as21.fsf@barnowl.research.intel-research.net>,
dgay@barnowl.research.intel-research.net writes:
|> "FredK" <fred.nospam@nospam.dec.com> writes:
|
|> > I've yet to find UNIX code that sticks to a convention, and that is
|> > remotely safe from boneheaded mistakes. Probably 80% or more
|> > of the code I've seen doesn't use C prototypes, which would
|> > have at least pointed out they wanted Delete() instead of delete() -
|> > each of which had different parameters (for an example).
|
|> I'm curious where such code comes from - can you say? Most (nearly all?) of
|> the code I see, i.e., mostly open source code, has prototypes.

Older code, mainly. Most open source code has been using ISO C
(or what it thinks is ISO C) for only 5-10 years - before 1995,
there were a LOT of systems which didn't have an even remotely
conforming compiler.

Well yes, but we are 10 years after that. And most of the code I saw in the
early 90s (again, mostly open source) used, at least, conditionally
compiled prototypes. gcc was available for most platforms in that time
frame. And conversion of existing code bases using tools like protoize
was fairly straightforward...

--
David Gay
dgay@acm.org
Back to top
Nick Maclaren
Guest
Posted: Wed Oct 05, 2005 10:29 pm    Post subject: Re: Regarding calculation of free memory Reply with quote
In article <79k6grc3fj.fsf@barnowl.research.intel-research.net>,
<dgay@barnowl.research.intel-research.net> wrote:
Quote:

|
|> I'm curious where such code comes from - can you say? Most (nearly all?) of
|> the code I see, i.e., mostly open source code, has prototypes.

Older code, mainly. Most open source code has been using ISO C
(or what it thinks is ISO C) for only 5-10 years - before 1995,
there were a LOT of systems which didn't have an even remotely
conforming compiler.

Well yes, but we are 10 years after that. And most of the code I saw in the
early 90s (again, mostly open source) used, at least, conditionally
compiled prototypes. gcc was available for most platforms in that time
frame. And conversion of existing code bases using tools like protoize
was fairly straightforward...

Hang on. That is ONLY 10 years - most software has a much longer life
than that - even source unchanged!

Firstly, gcc wasn't available for most platforms before 1995 - it was
available for the platforms used by most users - not the same thing,
at all, at all. And one of the most important platforms (Solaris)
didn't support ISO C until 1998 and not fully until a couple of years
back.

Secondly, conversion of clean codes using protoize was possible, but
why bother unless you were starting an update cycle? ISO C89 supports
the older form of function definition.

Thirdly, conversion of some codes (mostly, but not all, unclean) wasn't
possible because protoize couldn't (and probably can't) handle anything
other than simple code. I wrote some incredible preprocessor hacks
to make X11.3 usable (don't ask), which used prototypes and conformed
to the draft standard, and protoize (really don't ask) took one look
and collapsed in a heap.


Regards,
Nick Maclaren.
Back to top
Guest
Posted: Thu Oct 06, 2005 12:10 am    Post subject: Re: Regarding calculation of free memory Reply with quote
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
Quote:
In article <79k6grc3fj.fsf@barnowl.research.intel-research.net>,
dgay@barnowl.research.intel-research.net> wrote:

|
|> I'm curious where such code comes from - can you say? Most (nearly all?) of
|> the code I see, i.e., mostly open source code, has prototypes.

Older code, mainly. Most open source code has been using ISO C
(or what it thinks is ISO C) for only 5-10 years - before 1995,
there were a LOT of systems which didn't have an even remotely
conforming compiler.

Well yes, but we are 10 years after that. And most of the code I saw in the
early 90s (again, mostly open source) used, at least, conditionally
compiled prototypes. gcc was available for most platforms in that time
frame. And conversion of existing code bases using tools like protoize
was fairly straightforward...

Hang on. That is ONLY 10 years - most software has a much longer life
than that - even source unchanged!

Firstly, gcc wasn't available for most platforms before 1995 - it was
available for the platforms used by most users - not the same thing,
at all, at all. And one of the most important platforms (Solaris)
didn't support ISO C until 1998 and not fully until a couple of years
back.

However, gcc was essentially always available for Solaris (their may have
been a short delay after the first Solaris release, but I didn't notice
it at least).

Quote:
Secondly, conversion of clean codes using protoize was possible, but
why bother unless you were starting an update cycle? ISO C89 supports
the older form of function definition.

However, if you're not updating it, why is anyone looking at it?

Quote:
Thirdly, conversion of some codes (mostly, but not all, unclean) wasn't
possible because protoize couldn't (and probably can't) handle anything
other than simple code. I wrote some incredible preprocessor hacks
to make X11.3 usable (don't ask), which used prototypes and conformed
to the draft standard, and protoize (really don't ask) took one look
and collapsed in a heap.

I don't think X11 is typical of "most codes", though. Isn't it the one
which gives different signatures to the same function when viewed from
different modules?

--
David Gay
dgay@acm.org
Back to top
Guest
Posted: Thu Oct 06, 2005 12:15 am    Post subject: Re: Regarding calculation of free memory Reply with quote
Paul Keinanen <keinanen@sci.fi> writes:

Quote:
On 05 Oct 2005 08:42:46 -0700,
dgay@barnowl.research.intel-research.net wrote:

"FredK" <fred.nospam@nospam.dec.com> writes:

I've yet to find UNIX code that sticks to a convention, and that is
remotely safe from boneheaded mistakes. Probably 80% or more
of the code I've seen doesn't use C prototypes, which would
have at least pointed out they wanted Delete() instead of delete() -
each of which had different parameters (for an example).

I'm curious where such code comes from - can you say? Most (nearly all?) of
the code I see, i.e., mostly open source code, has prototypes.

Are you talking about Linux or Unix in general ?

I'm talking about the open source available in the late 80s onwards time
frame, so mostly Unix in general rather than Linux in particular. And some
amount was more cross-platform than that (e.g., emacs).

--
David Gay
dgay@acm.org
Back to top
Nick Maclaren
Guest
Posted: Thu Oct 06, 2005 12:15 am    Post subject: Re: Regarding calculation of free memory Reply with quote
In article <79fyrfbwzw.fsf@barnowl.research.intel-research.net>,
<dgay@barnowl.research.intel-research.net> wrote:
Quote:

However, gcc was essentially always available for Solaris (their may have
been a short delay after the first Solaris release, but I didn't notice
it at least).

The problem was in the libraries. Solaris didn't sort out even the
basics until 1995/6, didn't enable ISO C + POSIX codes until 1998
(Solaris 7) and didn't sort out all of the chaos until Solaris 9.

Still, it did better than a certain big blue company :-(

Quote:
I don't think X11 is typical of "most codes", though. Isn't it the one
which gives different signatures to the same function when viewed from
different modules?

Probably. It has included every other sin, crime and idiocy, so
why not complete the set?


Regards,
Nick Maclaren.
Back to top
Paul Keinanen
Guest
Posted: Thu Oct 06, 2005 12:15 am    Post subject: Re: Regarding calculation of free memory Reply with quote
On 05 Oct 2005 08:42:46 -0700,
dgay@barnowl.research.intel-research.net wrote:

Quote:
"FredK" <fred.nospam@nospam.dec.com> writes:

I've yet to find UNIX code that sticks to a convention, and that is
remotely safe from boneheaded mistakes. Probably 80% or more
of the code I've seen doesn't use C prototypes, which would
have at least pointed out they wanted Delete() instead of delete() -
each of which had different parameters (for an example).

I'm curious where such code comes from - can you say? Most (nearly all?) of
the code I see, i.e., mostly open source code, has prototypes.

Are you talking about Linux or Unix in general ?

At least I had to convert some sample client code for a communication
package to K&R so that the primitive compiler intended mainly for
compiling the Unix kernel cold compile it. In these systems in which
the client was intended to be used, the customer did not use these
systems for program development but only for production, so any
"modern" compiler would be missing.

Paul
Back to top
Albert van der Horst
Guest
Posted: Wed Oct 12, 2005 1:36 pm    Post subject: Re: Regarding calculation of free memory Reply with quote
In article <dhp6mi$7u3$1@gemini.csx.cam.ac.uk>,
Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
[quote]In article <5pCdnWbp1rsoKaLeRVnyuw@pipex.net>,
Steve at fivetrees <steve@NOSPAMTAfivetrees.com> wrote:
"Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message
news:dhobjl$e2v$1@gemini.csx.cam.ac.uk...
extreme_pedant_mode=ON

Not so. In Fortran 77, it was possible to allocate all memory statically,
but it isn't generally possible. It can't be done in Fortran 90 or C.

even_more_extreme_pedant_mode=ON

It *can* be done in C - by avoiding malloc ;).

even_more_extreme_pedant_mode=OFF

I will skip the mode nesting, as things are getting ridiculous :-)

Problem one: in C, there is no memory management beyond stack scoped
except by using malloc. Any algorithm that requires more than that
can't be done if you don't use malloc.
[/quote]
That is why so many serious real time application do their own
heap management. If the heap usage is simple, programming it yourself
may be not even be hard.

[quote]Problem two: there are many library facilities that use malloc either
explicitly or implicitly - including almost all I/O - you would have
to avoid them, too.
[/quote]
Yeah, you have to avoid printf c.s. They are mostly in the user interface
though. Most real time applications are split in a real real time part
and the user interface that is not. If you adapt this, you can use
printf freely in the user interface and the problem all but disappears.


[quote]

Regards,
Nick Maclaren.
[/quote]


--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
Back to top
Brian Hurt
Guest
Posted: Fri Nov 11, 2005 1:15 am    Post subject: Re: Regarding calculation of free memory Reply with quote
The first thing I'll comment is that Java has screwed up GC somehow- or at
least most Java implementations have, according to every Java programmer
I've ever talked to. But Java isn't the only GC out there- so I'll base my
comments on the Ocaml GC, because a) it fixes most of the problems Java
seems to have, and b) I know it well.

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:

Quote:
No. What I mean is that most garbage collection work ignores such
practical problems as diagnosing and handling memory exhaustion,

Other than throwing an exception, what else can the allocation
subsystem do?

GC does have a certain overhead of uncollected garbage- but standard
heap allocation also has the overhead of fragmented memory. But
copying GC has one advantage- before throwing the segv exception, it
can do a "hail mary pass" collection of the full memory space. And
if, by hook or crook, it manages to free up enough space to fullfill
the request, the system can stagger on (probably only for a little
while, but still). When that segv exception is thrown, the system
really will be out of memory. With malloc/free you can have lots of
chunks of unused memory, amounting to signifigant fractions (1/2) of
total memory, all of which are too small to fullfill the request.

Quote:
efficiency requirements,

If you need hard realtime, GC isn't there yet- and neither, I comment,
is malloc/free. The realtime programmers I know tend to be real big
on static pre-allocation. The said, GC can actually have a negative
performance cost- as the speed up to the rest of the program due to
cache effects (copying GC tends to "sort" memory, reducing cache
misses) can be greater than the cost of GC.

Quote:
and trapping user errors before they fill
up the memory with junk.

How is the memory system supposed to be able to tell the junk from the
not-junk?

Quote:
I think that old Appel's paper "garbage collection can be faster than
stack allocation" does provide valuable insight, even if the actual
figures may not be true today (because of cache issues, etc..)

They never were realistic. Yes, good garbage collection can be
faster than bad stack allocation. So what else is new?

I doubt it can be faster than stack allocation. It can be damned near
as fast. The common case for Ocaml on the x86 is 5 simple
instructions- a load, a subtract, a compare to memory, a branch
(almost certainly not taken), and a store. In C terms, it's
basically:

extern char * young_ptr;
extern char * young_limit;

static inline void * allocate(size_t size) {
register char * rval;
RESTART:
rval = young_ptr; /* a load */
rval -= size; /* a subtract */
if (rval < young_limit) { /* compare to memory and branch */
minor_collect(); /* generally not done */
goto RESTART;
}
young_ptr = rval; /* the store */
return rval;
}

This is slightly slower than alloca(), but not by much.

Brian
Back to top
 
Post new topic   Reply to topic    CASTalk.com Forum Index -> Computer Architecture All times are GMT
Goto page Previous  1, 2, 3, 4, 5
Page 5 of 5

 
 You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum




VoIP Electronics Powered by phpBB