Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Strange C developments

Reply
Thread Tools

Strange C developments

 
 
Nick Keighley
Guest
Posts: n/a
 
      07-30-2012
On Jul 24, 1:36ย*pm, Malcolm McLean <(E-Mail Removed)>
wrote:
> ื‘ืชืืจื™ืš ื™ื•ื ืฉืœื™ืฉื™, 24 ื‘ื™ื•ืœื™ 2012 09:23:03 UTC+1, ืžืืช Nick Keighley:> On Jul 21, 6:03ย*pm, jacob navia '(E-Mail Removed)' wrote:
>
> > whilst that's impressive even a milisecond might matter in some real
> > time systems

>
> You've got twenty of them per frame in a 50 frames per second video system. So the garbage collector itself won't take down the system. However it'snot a negligible consumer of resources.


I didn't say "video" did I?
 
Reply With Quote
 
 
 
 
Nick Keighley
Guest
Posts: n/a
 
      07-30-2012
On Jul 27, 7:47*pm, "io_x" <(E-Mail Removed)> wrote:
> "Nick Keighley" <(E-Mail Removed)> ha scritto nel messaggionews:(E-Mail Removed)...
> On Jul 22, 9:37 am, "io_x" <(E-Mail Removed)> wrote:
>
>
>
>
>
> > "Tim Rentsch" <(E-Mail Removed)> ha scritto nel
> > messaggionews:(E-Mail Removed)...

>
> > > If you have a large program that extensively uses malloc() and
> > > manual reclamation, it would be great to have it converted
> > > to use GC and see what the performance is like. I would love
> > > to have a counter-point to offer to the GC fans.

>
> > the conter-point is simply this: programmer has to think
> > on memory of his/her program...

>
> > > Of course,
> > > if you do run some sort of comparison, it's important to try
> > > to make it a fair comparison -- obviously the results can be
> > > slanted one way or the other by choosing how one program is
> > > transformed into the other.

>
> > you can not compare what you control of what you not controll
> > at all...
> > if someone want to be a programer, he/she has to build his/her own
> > malloc routines only for to have more
> > controll hisself/herself program memory...
> > so the way is opposite of use gc() etc...

>
> nonsense
>
> #the nonsense is almost all [but 2 people not] that write here
> #have fear in think or managiament memory they programs use


incomprehensible.

if I guess right you suggest I'm scared to write my own version of
malloc.
I simply don't see the point. I've written fixed block allocators.
Since
malloc() is suppiled with my C library I've had no compulsion to write
my own.
Life's too short.

 
Reply With Quote
 
 
 
 
BartC
Guest
Posts: n/a
 
      07-30-2012
"Nick Keighley" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Jul 27, 7:47 pm, "io_x" <(E-Mail Removed)> wrote:


>> #the nonsense is almost all [but 2 people not] that write here
>> #have fear in think or managiament memory they programs use

>
> incomprehensible.
>
> if I guess right you suggest I'm scared to write my own version of
> malloc.
> I simply don't see the point.


One of the benchmarks[1] I was using on my compiler project was,
miraculously, faster than gcc, no matter what the latter's optimisation
level.

Ie. always 4.2 seconds, compared with gcc's 5.6 seconds. Then I discovered
the timing of this benchmark is mostly based around calls to malloc() and
free(). Two other C compilers were both around 2.4 seconds. I was using
lcc-win's library.

I plugged in my own allocator, built on top of malloc(), which was better at
lots of small allocations, and my timing was then 1.2 seconds!

So, you were saying about there not being any point? (Of course this was not
rewriting malloc(), but the large memory blocks I worked with could just as
easily have come from the OS, and given had the same results.)

(Sadly I had to retire this benchmark, as it was not actually testing
generated code.)

[1]
http://shootout.alioth.debian.org/u3...&lang=gcc&id=1

--
Bartc

 
Reply With Quote
 
tom st denis
Guest
Posts: n/a
 
      08-02-2012
On Jul 20, 7:03*pm, "christian.bau" <(E-Mail Removed)>
wrote:
> On Jul 20, 10:14*pm, Jase Schick <(E-Mail Removed)> wrote:
>
> > Hi Can anyone explain why C has added support for pthreads, while NOT
> > adding support for garbage collection? Convenient memory management would
> > be a much greater enhancement than replicating a perfectly good existing
> > library it seems to me.

>
> Interestingly, Apple just killed garbage collection in their Objective-
> C compilers and never moved support for GC to the iPhone.
> So someone there thinks that garbage collection isn't _that_ useful.
> And sorry to say, but C wasn't designed with garbage collection in
> mind.


Syntactically it'd be pretty easy to have something like

heap int *p;

where "heap" defaults to init it to NULL and then at the end a call to
free() is made automatically.

That sort of syntax would make certain functions a bit easier to work
with, infinitely more useful would be something like

heap int foo[34]; // or whatever array size

Where it allocates "foo" off the heap (via calloc) automagically,
raising a signal if it fails, and then when the function returns it
calls free() on it.

That would be very useful for small stackframe applications.
 
Reply With Quote
 
88888 Dihedral
Guest
Posts: n/a
 
      08-02-2012
BGBๆ–ผ 2012ๅนด7ๆœˆ24ๆ—ฅๆ˜ŸๆœŸไบŒUTC+8ไธ‹ๅˆ10ๆ™‚55ๅˆ†33็ง ’ๅฏซ้“๏ผš
> On 7/24/2012 3:23 AM, Nick Keighley wrote:
>
> > On Jul 21, 6:03 pm, jacob navia <(E-Mail Removed)> wrote:

>
> >

>
> >> 2) In modern machines a collector slows down the program for at most

>
> >> a milisecond in normal situations, that could be bigger but not much

>
> >> bigger since the collector tries to spread out the GC time in each

>
> >> allocation.

>
> >

>
> > whilst that's impressive even a milisecond might matter in some real

>
> > time systems

>
> >

>
>
>
> hard real-time, maybe.
>
> then the usual strategy would be not to use a GC.
>
> in any case, it would be best if C preserved the right to choice as to
>
> whether or not GC is used.
>
>
>
>
>
> soft real-time is, well, softer. typically, the matter of whether or not
>
> a GC is used can be more left to the impact it may have on the user
>
> experience. assuming that the GC is not running all the time (this is
>
> likely only really in pathological conditions), the negative impact is
>
> fairly small, but may allow delivering a better user experience overall
>
> (while at the same time, preventing slower memory leaks from eventually
>
> crashing the program).
>
>
>
> speed critical code may also refrain from allocating memory or using
>
> dynamic type-checking as well.
>
>
>
>
>
> actually, as-is, GC libraries supply a choice as to whether or not GC is
>
> used, apart from people arguing that "there is no choice, since they are
>
> unusable".
>
>
>
> any sort of standard GC would likely still need to preserve choice, and
>
> hopefully not be too far in "lame duck" territory either.
>
>
>
>
>
>
>
> decided to leave out anecdotes related to my experience plugging my GC
>
> into the Quake 2 "hunk"-allocator system (basically, memory allocation
>
> in a manner similar to a large stack).


The GC part can be implememted by reference counts.
But that adds overheads to using every objet.

There is another way to achieve the same funtionalities as the GC.

But that will involve error trapping and serializing objects to be storable to the hard disk, and perform jobs in a shell way that can be safely exited in all modules.

It is as difficult as building the OS mmu part.




 
Reply With Quote
 
Jens Gustedt
Guest
Posts: n/a
 
      08-02-2012
Am 02.08.2012 15:08, schrieb tom st denis:
> Syntactically it'd be pretty easy to have something like
>
> heap int *p;
>
> where "heap" defaults to init it to NULL and then at the end a call to
> free() is made automatically.
>
> That sort of syntax would make certain functions a bit easier to work
> with, infinitely more useful would be something like
>
> heap int foo[34]; // or whatever array size
>
> Where it allocates "foo" off the heap (via calloc) automagically,
> raising a signal if it fails, and then when the function returns it
> calls free() on it.
>
> That would be very useful for small stackframe applications.


Why would you need such a "heap" marker syntactically?

For your first example for the pointer (syntactically) I would just do

int foo[1];

An implementation could just decide to allocate "auto" arrays on the
heap, and free everything at the end of the liftime of the variable. You
don't have to add a jota to the syntax of C for that.

The downside of such a "heap" approach for array allocation is that the
implementation of setjmp/longjmp would be come a bit more complicated.
You can't just re-adjust the stack pointer but you'd have to re-invent a
mechanism that "free"s all the allocated arrays on the way down, once
you jump to a different function stack. Isn't completely trivial.

Jens


* Unbekannt - erkannt
* Englisch
* Deutsch

* Englisch
* Deutsch

<javascript:void(0);> <#>
 
Reply With Quote
 
gwowen
Guest
Posts: n/a
 
      08-03-2012
On Aug 2, 2:08*pm, tom st denis <(E-Mail Removed)> wrote:

> Syntactically it'd be pretty easy to have something like
>
> heap int *p;
>
> where "heap" defaults to init it to NULL and then at the end a call to
> free() is made automatically... infinitely more useful would be somethinglike
>
> heap int foo[34]; // or whatever array size
>
> Where it allocates "foo" off the heap (via calloc) automagically,
> raising a signal if it fails, and then when the function returns it
> calls free() on it.
>
> That would be very useful for small stackframe applications.


Replace "signal" with exception, and you've just (re-)invented the key
point of of C++ RAII? Personally, I find resource management with
RAII far more convenient than GC -- though I appreciate that GC has
some advantages -- as it works for more than memory.

In fact, RAII is the single biggest thing that makes C++'s esoteric
horrors worth putting up with.
 
Reply With Quote
 
tom st denis
Guest
Posts: n/a
 
      08-03-2012
On Aug 2, 3:23*pm, Jens Gustedt <(E-Mail Removed)> wrote:
> Am 02.08.2012 15:08, schrieb tom st denis:
>
>
>
>
>
>
>
>
>
> > Syntactically it'd be pretty easy to have something like

>
> > heap int *p;

>
> > where "heap" defaults to init it to NULL and then at the end a call to
> > free() is made automatically.

>
> > That sort of syntax would make certain functions a bit easier to work
> > with, infinitely more useful would be something like

>
> > heap int foo[34]; // or whatever array size

>
> > Where it allocates "foo" off the heap (via calloc) automagically,
> > raising a signal if it fails, and then when the function returns it
> > calls free() on it.

>
> > That would be very useful for small stackframe applications.

>
> Why would you need such a "heap" marker syntactically?
>
> For your first example for the pointer (syntactically) I would just do
>
> int foo[1];
>
> An implementation could just decide to allocate "auto" arrays on the
> heap, and free everything at the end of the liftime of the variable. You
> don't have to add a jota to the syntax of C for that.
>
> The downside of such a "heap" approach for array allocation is that the
> implementation of setjmp/longjmp would be come a bit more complicated.
> You can't just re-adjust the stack pointer but you'd have to re-invent a
> mechanism that "free"s all the allocated arrays on the way down, once
> you jump to a different function stack. Isn't completely trivial.


Are there real people who use setjmp()/etc in everyday code? I've
never once used them despite all the oddball places my code has been
found.

And while the compiler could automagically decide to take from the
heap for auto variables it would be nice for that to be more manual.

Tom
 
Reply With Quote
 
Noob
Guest
Posts: n/a
 
      08-03-2012
tom st denis wrote:

> Are there real people who use setjmp()/etc in everyday code? I've
> never once used them despite all the oddball places my code has been
> found.


IJG's libjpeg uses longjmp to bail out on error o_O
(I suppose the author didn't want to propagate errors.)
Kinda hairy, in my opinion.

 
Reply With Quote
 
Anders Wegge Keller
Guest
Posts: n/a
 
      08-03-2012
tom st denis <(E-Mail Removed)> writes:

> Are there real people who use setjmp()/etc in everyday code? I've
> never once used them despite all the oddball places my code has been
> found.


if (timeout) {
signal (SIGALRM, alarm_int);
alarm (timeout) ;
}
if (setjmp (timrenv) == 0) {
retval = routine (param1, param2) ;
/* this is a normal return */
} else {
/* we come here after a timeout */

Our codebase have several places where timeouts are handled by
setjmp/longjmp as the snippet above. The alarm handler finish with a
longjmp(). This is legacy code, originally deployed on Xenix. I've
been lead to beleive that this was the only reliable way of handling
socket timeouts on that platform.

--
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Spot Future Trends and Developments in the Recorded DVD & Video Market in the United Kingdom (Business Wire via Yahoo! Finance) admin@ng2000.com DVD Video 0 02-12-2007 08:02 AM
Quick survey on tools to increase quality in Java/J2EE developments & bet to win Champagne marc.rambert@gmail.com Java 0 03-15-2006 11:19 AM
(off topic) GOT-STL-P (Re: Interesting developments since "Beating the averages"?) alex.gman@gmail.com C++ 1 02-11-2006 05:10 PM
Some of the recent developments of the ISO C++ front Ioannis Vranos C++ 0 10-29-2004 09:14 PM
Interesting Blue-Ray developments poldy DVD Video 0 06-23-2004 03:52 AM



Advertisments