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

Groups > comp.arch.embedded > #27200 > unrolled thread

Embedded platforms for beginners?

Back to article view | Back to comp.arch.embedded

Contents

  Embedded platforms for beginners? Elof Huang <elof.huang@runbox.com> - 2017-09-01 14:07 +0800
    Re: Embedded platforms for beginners? Jack <jack4747@gmail.com> - 2017-08-31 23:22 -0700
    Re: Embedded platforms for beginners? rickman <gnuarm@gmail.com> - 2017-09-01 04:10 -0400
    Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-01 21:49 +1000
      Re: Embedded platforms for beginners? Elof Huang <elof.huang@runbox.com> - 2017-09-02 11:57 +0800
        Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-02 18:25 +1000
          Re: Embedded platforms for beginners? Elof Huang <elof.huang@runbox.com> - 2017-09-03 15:37 +0800
            Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-03 17:54 +1000
            Re: Embedded platforms for beginners? rickman <gnuarm@gmail.com> - 2017-09-03 13:49 -0400
      Re: Embedded platforms for beginners? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-02 11:41 -0400
        Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-03 09:44 +1000
          Re: Embedded platforms for beginners? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-02 20:39 -0400
            Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-03 11:16 +1000
          Re: Embedded platforms for beginners? Paul Rubin <no.email@nospam.invalid> - 2017-09-02 18:21 -0700
            Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-03 14:26 +1000
              Re: Embedded platforms for beginners? rickman <gnuarm@gmail.com> - 2017-09-03 02:14 -0400
                Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-03 17:52 +1000
                  Re: Embedded platforms for beginners? rickman <gnuarm@gmail.com> - 2017-09-03 13:50 -0400
                    Re: Embedded platforms for beginners? Paul Rubin <no.email@nospam.invalid> - 2017-09-03 22:20 -0700
                      Re: Embedded platforms for beginners? rickman <gnuarm@gmail.com> - 2017-09-05 22:06 -0400
                        Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-06 12:21 +1000
                          Re: Embedded platforms for beginners? rickman <gnuarm@gmail.com> - 2017-09-05 22:42 -0400
                            Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-06 14:26 +1000
                              Re: Embedded platforms for beginners? rickman <gnuarm@gmail.com> - 2017-09-06 01:20 -0400
                  Re: Embedded platforms for beginners? George Neuner <gneuner2@comcast.net> - 2017-09-03 15:58 -0400
                    Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-04 08:00 +1000
                      Re: Embedded platforms for beginners? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-03 19:13 -0400
                        Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-04 09:58 +1000
                          Re: Embedded platforms for beginners? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-03 20:16 -0400
                            Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-04 15:13 +1000
                              Re: Embedded platforms for beginners? Paul Rubin <no.email@nospam.invalid> - 2017-09-03 22:24 -0700
                                Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-04 15:55 +1000
                                  Re: Embedded platforms for beginners? David Brown <david.brown@hesbynett.no> - 2017-09-05 14:15 +0200
                                    Re: Embedded platforms for beginners? George Neuner <gneuner2@comcast.net> - 2017-09-05 12:35 -0400
                                      Re: Embedded platforms for beginners? Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2017-09-05 10:02 -0700
                                        Re: Embedded platforms for beginners? Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-09-05 18:13 +0100
                                        Re: Embedded platforms for beginners? David Brown <david.brown@hesbynett.no> - 2017-09-06 10:24 +0200
                                      Re: Embedded platforms for beginners? Paul Rubin <no.email@nospam.invalid> - 2017-09-05 17:10 -0700
                                      Re: Embedded platforms for beginners? David Brown <david.brown@hesbynett.no> - 2017-09-06 09:57 +0200
                                    Re: Embedded platforms for beginners? Paul Rubin <no.email@nospam.invalid> - 2017-09-05 16:57 -0700
                                  Re: Embedded platforms for beginners? Paul Rubin <no.email@nospam.invalid> - 2017-09-05 16:54 -0700
                                    Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-06 12:31 +1000
                                      Re: Embedded platforms for beginners? Paul Rubin <no.email@nospam.invalid> - 2017-09-05 19:42 -0700
                                Re: Embedded platforms for beginners? David Brown <david.brown@hesbynett.no> - 2017-09-05 10:16 +0200
                              Re: Embedded platforms for beginners? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-05 16:56 -0400
                        Re: Embedded platforms for beginners? Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-09-04 10:46 +0100
                          Re: Embedded platforms for beginners? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-05 17:09 -0400
                            Re: Embedded platforms for beginners? Paul Rubin <no.email@nospam.invalid> - 2017-09-05 19:35 -0700
                              Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-06 12:40 +1000
                              Re: Embedded platforms for beginners? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-06 00:42 -0400
                                Re: Embedded platforms for beginners? Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-09-06 08:55 +0100
                            Re: Embedded platforms for beginners? Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-09-06 08:45 +0100
                              Re: Embedded platforms for beginners? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-07 20:23 -0400
                                Re: Embedded platforms for beginners? Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-09-08 08:42 +0100
                                  Re: Embedded platforms for beginners? David Brown <david.brown@hesbynett.no> - 2017-09-08 12:07 +0200
                                    Re: Embedded platforms for beginners? Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-09-08 11:40 +0100
                                      Re: Embedded platforms for beginners? David Brown <david.brown@hesbynett.no> - 2017-09-08 13:24 +0200
                                        Re: Embedded platforms for beginners? Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-09-08 13:36 +0100
                                        Re: Embedded platforms for beginners? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-09 13:16 -0400
                                          Re: Embedded platforms for beginners? Les Cargill <lcargill99@comcast.com> - 2017-09-10 08:53 -0500
                                            Re: Embedded platforms for beginners? Dimiter_Popoff <dp@tgi-sci.com> - 2017-09-10 20:18 +0300
                                            Re: Embedded platforms for beginners? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-11 21:24 -0400
                                              Re: Embedded platforms for beginners? Les Cargill <lcargill99@comcast.com> - 2017-09-15 22:22 -0500
                                                Re: Embedded platforms for beginners? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-18 11:26 -0400
                                                  Re: Embedded platforms for beginners? Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-09-18 18:26 +0100
                                                    Re: Embedded platforms for beginners? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-19 14:27 -0400
                                                Re: Embedded platforms for beginners? Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-09-18 18:24 +0100
                    Re: Embedded platforms for beginners? Paul Rubin <no.email@nospam.invalid> - 2017-09-03 22:30 -0700
                      Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-04 15:51 +1000
              Re: Embedded platforms for beginners? Paul Rubin <no.email@nospam.invalid> - 2017-09-03 22:04 -0700
        Re: Embedded platforms for beginners? kristoff <kristoff@skypro.be> - 2017-09-05 17:56 +0200
          Re: Embedded platforms for beginners? Luke A. Guest <laguest@archeia.com> - 2017-09-10 17:10 +0100
    Re: Embedded platforms for beginners? tarjei99@gmail.com - 2017-09-10 05:49 -0700
      Re: Embedded platforms for beginners? Les Cargill <lcargill99@comcast.com> - 2017-09-10 09:03 -0500

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

#27253

On 06/09/17 12:06, rickman wrote:
> Paul Rubin wrote on 9/4/2017 1:20 AM:
>> rickman <gnuarm@gmail.com> writes:
>>> It's not like "GC'd" is a commonly used abbreviation.
>>
>> At least among language geeks, it's definitely commonly used.
> 
> Exactly, when you are talking to people who already know what you are 
> talking about.

Most people would just Google "memory gc" to educate themselves,
rather than bleating about how ignorant they are. "Garbage
Collection" is the very first hit on Google. But instead of
you spending 30 seconds learning something, a hundred or more
people have had to spend 30 seconds reading unnecessary posts.

Clifford Heath.

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

#27258

Clifford Heath wrote on 9/5/2017 10:21 PM:
> On 06/09/17 12:06, rickman wrote:
>> Paul Rubin wrote on 9/4/2017 1:20 AM:
>>> rickman <gnuarm@gmail.com> writes:
>>>> It's not like "GC'd" is a commonly used abbreviation.
>>>
>>> At least among language geeks, it's definitely commonly used.
>>
>> Exactly, when you are talking to people who already know what you are
>> talking about.
>
> Most people would just Google "memory gc" to educate themselves,
> rather than bleating about how ignorant they are. "Garbage
> Collection" is the very first hit on Google. But instead of
> you spending 30 seconds learning something, a hundred or more
> people have had to spend 30 seconds reading unnecessary posts.

Exactly.  I see dozens of un-useful abbreviations in newsgroups every day. 
They waste people's time.  In this case it wasn't just mine.  The rule for 
use of abbreviations in documents is to explain the abbreviation the first 
time it is used in a doc.  It would be a good rule for usage in a thread.

-- 

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

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

#27260

On 06/09/17 12:42, rickman wrote:
> Clifford Heath wrote on 9/5/2017 10:21 PM:
>> On 06/09/17 12:06, rickman wrote:
>>> Paul Rubin wrote on 9/4/2017 1:20 AM:
>>>> rickman <gnuarm@gmail.com> writes:
>>>>> It's not like "GC'd" is a commonly used abbreviation.
>>>>
>>>> At least among language geeks, it's definitely commonly used.
>>>
>>> Exactly, when you are talking to people who already know what you are
>>> talking about.
>>
>> Most people would just Google "memory gc" to educate themselves,
>> rather than bleating about how ignorant they are. "Garbage
>> Collection" is the very first hit on Google. But instead of
>> you spending 30 seconds learning something, a hundred or more
>> people have had to spend 30 seconds reading unnecessary posts.
> 
> Exactly.  I see dozens of un-useful abbreviations in newsgroups every 
> day. They waste people's time.  In this case it wasn't just mine.  The 
> rule for use of abbreviations in documents is to explain the 
> abbreviation the first time it is used in a doc.  It would be a good 
> rule for usage in a thread.

This industry is characterized by lots of jargon and acronyms.
The most desirable quality in selecting a new hire is that they
show a propensity and enthusiasm for finding things out by
themselves, rather than asking other people.

By the way, how's the job hunt going? Keep going, you're sure
to make it some year.

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

#27261

Clifford Heath wrote on 9/6/2017 12:26 AM:
> On 06/09/17 12:42, rickman wrote:
>> Clifford Heath wrote on 9/5/2017 10:21 PM:
>>> On 06/09/17 12:06, rickman wrote:
>>>> Paul Rubin wrote on 9/4/2017 1:20 AM:
>>>>> rickman <gnuarm@gmail.com> writes:
>>>>>> It's not like "GC'd" is a commonly used abbreviation.
>>>>>
>>>>> At least among language geeks, it's definitely commonly used.
>>>>
>>>> Exactly, when you are talking to people who already know what you are
>>>> talking about.
>>>
>>> Most people would just Google "memory gc" to educate themselves,
>>> rather than bleating about how ignorant they are. "Garbage
>>> Collection" is the very first hit on Google. But instead of
>>> you spending 30 seconds learning something, a hundred or more
>>> people have had to spend 30 seconds reading unnecessary posts.
>>
>> Exactly.  I see dozens of un-useful abbreviations in newsgroups every day.
>> They waste people's time.  In this case it wasn't just mine.  The rule for
>> use of abbreviations in documents is to explain the abbreviation the first
>> time it is used in a doc.  It would be a good rule for usage in a thread.
>
> This industry is characterized by lots of jargon and acronyms.
> The most desirable quality in selecting a new hire is that they
> show a propensity and enthusiasm for finding things out by
> themselves, rather than asking other people.
>
> By the way, how's the job hunt going? Keep going, you're sure
> to make it some year.

Obviously you don't understand newsgroups if you think this is a job 
interview.  This is a discussion group.  Many people come from different 
backgrounds with different levels of familiarity of the jargon of any 
particular micro-area of knowledge.  If you want to be able to communicate 
you won't express every thought with the minimum amount of keystrokes.  The 
term is garbage collection.  It's not that had to type.  Just like *many* 
other abbreviations it is often not worth using since it just isn't that 
much harder to type the name.

-- 

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

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

#27219

On Sun, 3 Sep 2017 17:52:42 +1000, Clifford Heath <no.spam@please.net>
wrote:

>On 03/09/17 16:14, rickman wrote:
>
>> 
>> What is GC?
>
>Garbage collection. Make new objects and just lose them,
>the GC will pick them up. You never know when the GC will
>run, and you need a *lot* more memory, 

Those are misconceptions: there are systems that are completely
deterministic, others that are very predictable (e.g., GC is
schedulable in particular time slots, won't exceed given percentage of
CPU time, etc.), and systems that don't need much additional memory.  

There even are systems that combine predictability with low memory
overhead.


It is absolutely true that GC requires *some* extra room and *some*
extra CPU cycles wrt a non-GC system ... but the notion that GC is
something unpredictable is a misconceived generalization of behavior
that is implementation dependent.

You may dislike GC and that is fine, but please don't go spreading
FUD.  Many GC runtimes are intended for desktop/server use, and those
are inappropriate for small or RT systems - but that doesn't mean all
of them are.


>so it's not a good way to get the most out of an MCU.

I would say it it depends on the system.  My position is that GC has
no place in a small system.  OTOH, if you're talking about a complex
system with 32-bit controller and 100s of KB (or more) of RAM ...

George

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

#27220

On 04/09/17 05:58, George Neuner wrote:
> On Sun, 3 Sep 2017 17:52:42 +1000, Clifford Heath <no.spam@please.net>
> wrote:
> 
>> On 03/09/17 16:14, rickman wrote:
>>> What is GC?
>>
>> Garbage collection. Make new objects and just lose them,
>> the GC will pick them up. You never know when the GC will
>> run, and you need a *lot* more memory,
> 
> Those are misconceptions: there are systems that are completely
> deterministic, others that are very predictable (e.g., GC is
> schedulable in particular time slots, won't exceed given percentage of
> CPU time, etc.), and systems that don't need much additional memory.
> 
> There even are systems that combine predictability with low memory
> overhead.

All that is true. None of it invalidates what I said.

>> so it's not a good way to get the most out of an MCU.
> 
> I would say it it depends on the system.
> My position is that GC has no place in a small system.

Thanks for confirming my position.

> OTOH, if you're talking about a complex
> system with 32-bit controller and 100s of KB (or more) of RAM ...

Then you have resources in such excess that *you don't need*
to get the best out of it. Exactly what I said, in other words.

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

#27221

On 09/03/2017 06:00 PM, Clifford Heath wrote:
> On 04/09/17 05:58, George Neuner wrote:
>> On Sun, 3 Sep 2017 17:52:42 +1000, Clifford Heath <no.spam@please.net>
>> wrote:
>>
>>> On 03/09/17 16:14, rickman wrote:
>>>> What is GC?
>>>
>>> Garbage collection. Make new objects and just lose them,
>>> the GC will pick them up. You never know when the GC will
>>> run, and you need a *lot* more memory,
>>
>> Those are misconceptions: there are systems that are completely
>> deterministic, others that are very predictable (e.g., GC is
>> schedulable in particular time slots, won't exceed given percentage of
>> CPU time, etc.), and systems that don't need much additional memory.
>>
>> There even are systems that combine predictability with low memory
>> overhead.
> 
> All that is true. None of it invalidates what I said.
> 
>>> so it's not a good way to get the most out of an MCU.
>>
>> I would say it it depends on the system.
>> My position is that GC has no place in a small system.
> 
> Thanks for confirming my position.

Well, given that dynamic allocation has no place in small systems 
either, GC is a bit of a non-issue. ;)

> 
>> OTOH, if you're talking about a complex
>> system with 32-bit controller and 100s of KB (or more) of RAM ...
> 
> Then you have resources in such excess that *you don't need*
> to get the best out of it. Exactly what I said, in other words.

Until it's been running long enough that the heap is fragmented into 
tiny, tiny bits.

Cheers

Phil Hobbs


-- 
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

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

#27222

On 04/09/17 09:13, Phil Hobbs wrote:
> On 09/03/2017 06:00 PM, Clifford Heath wrote:
>> On 04/09/17 05:58, George Neuner wrote:
>>> On Sun, 3 Sep 2017 17:52:42 +1000, Clifford Heath <no.spam@please.net>
>>> wrote:
>>>
>>>> On 03/09/17 16:14, rickman wrote:
>>>>> What is GC?
>>>>
>>>> Garbage collection. Make new objects and just lose them,
>>>> the GC will pick them up. You never know when the GC will
>>>> run, and you need a *lot* more memory,
>>>
>>> Those are misconceptions: there are systems that are completely
>>> deterministic, others that are very predictable (e.g., GC is
>>> schedulable in particular time slots, won't exceed given percentage of
>>> CPU time, etc.), and systems that don't need much additional memory.
>>>
>>> There even are systems that combine predictability with low memory
>>> overhead.
>>
>> All that is true. None of it invalidates what I said.
>>
>>>> so it's not a good way to get the most out of an MCU.
>>>
>>> I would say it it depends on the system.
>>> My position is that GC has no place in a small system.
>>
>> Thanks for confirming my position.
> 
> Well, given that dynamic allocation has no place in small systems 
> either, GC is a bit of a non-issue. ;)
> 
>>
>>> OTOH, if you're talking about a complex
>>> system with 32-bit controller and 100s of KB (or more) of RAM ...
>>
>> Then you have resources in such excess that *you don't need*
>> to get the best out of it. Exactly what I said, in other words.
> 
> Until it's been running long enough that the heap is fragmented into 
> tiny, tiny bits.

Modern generational GC compacts the heap quite effectively.
The only real difficulties are (a) doing that unobtrusively
and (b) being certain that you won't ever run out of memory
due to leaks.

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

#27223

On 09/03/2017 07:58 PM, Clifford Heath wrote:
> On 04/09/17 09:13, Phil Hobbs wrote:
>> On 09/03/2017 06:00 PM, Clifford Heath wrote:
>>> On 04/09/17 05:58, George Neuner wrote:
>>>> On Sun, 3 Sep 2017 17:52:42 +1000, Clifford Heath <no.spam@please.net>
>>>> wrote:
>>>>
>>>>> On 03/09/17 16:14, rickman wrote:
>>>>>> What is GC?
>>>>>
>>>>> Garbage collection. Make new objects and just lose them,
>>>>> the GC will pick them up. You never know when the GC will
>>>>> run, and you need a *lot* more memory,
>>>>
>>>> Those are misconceptions: there are systems that are completely
>>>> deterministic, others that are very predictable (e.g., GC is
>>>> schedulable in particular time slots, won't exceed given percentage of
>>>> CPU time, etc.), and systems that don't need much additional memory.
>>>>
>>>> There even are systems that combine predictability with low memory
>>>> overhead.
>>>
>>> All that is true. None of it invalidates what I said.
>>>
>>>>> so it's not a good way to get the most out of an MCU.
>>>>
>>>> I would say it it depends on the system.
>>>> My position is that GC has no place in a small system.
>>>
>>> Thanks for confirming my position.
>>
>> Well, given that dynamic allocation has no place in small systems 
>> either, GC is a bit of a non-issue. ;)
>>
>>>
>>>> OTOH, if you're talking about a complex
>>>> system with 32-bit controller and 100s of KB (or more) of RAM ...
>>>
>>> Then you have resources in such excess that *you don't need*
>>> to get the best out of it. Exactly what I said, in other words.
>>
>> Until it's been running long enough that the heap is fragmented into 
>> tiny, tiny bits.
> 
> Modern generational GC compacts the heap quite effectively.
> The only real difficulties are (a) doing that unobtrusively
> and (b) being certain that you won't ever run out of memory
> due to leaks.

I assume that you haven't got a lot of aliased pointers running round 
your code!

Cheers

Phil Hobbs

-- 
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

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

#27225

On 04/09/17 10:16, Phil Hobbs wrote:
> On 09/03/2017 07:58 PM, Clifford Heath wrote:
>> On 04/09/17 09:13, Phil Hobbs wrote:
>>> On 09/03/2017 06:00 PM, Clifford Heath wrote:
>>>> On 04/09/17 05:58, George Neuner wrote:
>>>>> On Sun, 3 Sep 2017 17:52:42 +1000, Clifford Heath <no.spam@please.net>
>>>>> wrote:
>>>>>
>>>>>> On 03/09/17 16:14, rickman wrote:
>>>>>>> What is GC?
>>>>>>
>>>>>> Garbage collection. Make new objects and just lose them,
>>>>>> the GC will pick them up. You never know when the GC will
>>>>>> run, and you need a *lot* more memory,
>>>>>
>>>>> Those are misconceptions: there are systems that are completely
>>>>> deterministic, others that are very predictable (e.g., GC is
>>>>> schedulable in particular time slots, won't exceed given percentage of
>>>>> CPU time, etc.), and systems that don't need much additional memory.
>>>>>
>>>>> There even are systems that combine predictability with low memory
>>>>> overhead.
>>>>
>>>> All that is true. None of it invalidates what I said.
>>>>
>>>>>> so it's not a good way to get the most out of an MCU.
>>>>>
>>>>> I would say it it depends on the system.
>>>>> My position is that GC has no place in a small system.
>>>>
>>>> Thanks for confirming my position.
>>>
>>> Well, given that dynamic allocation has no place in small systems 
>>> either, GC is a bit of a non-issue. ;)
>>>
>>>>
>>>>> OTOH, if you're talking about a complex
>>>>> system with 32-bit controller and 100s of KB (or more) of RAM ...
>>>>
>>>> Then you have resources in such excess that *you don't need*
>>>> to get the best out of it. Exactly what I said, in other words.
>>>
>>> Until it's been running long enough that the heap is fragmented into 
>>> tiny, tiny bits.
>>
>> Modern generational GC compacts the heap quite effectively.
>> The only real difficulties are (a) doing that unobtrusively
>> and (b) being certain that you won't ever run out of memory
>> due to leaks.
> 
> I assume that you haven't got a lot of aliased pointers running round 
> your code!

Generational GC relies on being able to move things between heaps,
so object handles cannot be pointers (or rather, must be indirect).
Languages that do it don't allow you to see the pointer as a number.
... another reason why you can't get the most out of the hardware.

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

#27227

Clifford Heath <no.spam@please.net> writes:
> Generational GC relies on being able to move things between heaps,
> so object handles cannot be pointers (or rather, must be indirect).

The handles are usually still pointers.  First you copy the object to
the other heap, then later you scan it, copy the objects that the first
objects points to, and update the pointers in the first object to point
to the new locations.  This is described pretty well in the SICP chapter
on metacircular evaluators (mitpress.mit.edu/sicp).

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

#27230

On 04/09/17 15:24, Paul Rubin wrote:
> Clifford Heath <no.spam@please.net> writes:
>> Generational GC relies on being able to move things between heaps,
>> so object handles cannot be pointers (or rather, must be indirect).
> 
> The handles are usually still pointers.  First you copy the object to
> the other heap, then later you scan it, copy the objects that the first
> objects points to, and update the pointers in the first object to point
> to the new locations.  This is described pretty well in the SICP chapter
> on metacircular evaluators (mitpress.mit.edu/sicp).

Paul,

Please, why don't you copy/paste all the content from
http://www.memorymanagement.org/
There might be some people here who have not read it all yet.
Sigh... Yes, there is a whole domain of science here.
Far, far more than you have reminded us of yet.

No, it's *still* not the way to get the best from
most embedded hardware. It's an acceptable compromise,
some of the time, is all that can really be said.

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

#27236

On 04/09/17 07:55, Clifford Heath wrote:
> On 04/09/17 15:24, Paul Rubin wrote:
>> Clifford Heath <no.spam@please.net> writes:
>>> Generational GC relies on being able to move things between heaps,
>>> so object handles cannot be pointers (or rather, must be indirect).
>>
>> The handles are usually still pointers.  First you copy the object to
>> the other heap, then later you scan it, copy the objects that the first
>> objects points to, and update the pointers in the first object to point
>> to the new locations.  This is described pretty well in the SICP chapter
>> on metacircular evaluators (mitpress.mit.edu/sicp).
> 
> Paul,
> 
> Please, why don't you copy/paste all the content from
> http://www.memorymanagement.org/
> There might be some people here who have not read it all yet.
> Sigh... Yes, there is a whole domain of science here.
> Far, far more than you have reminded us of yet.

I had a little look at that site.  It had some useful explanations, but
is /seriously/ biased.  It gives the impression that the only reason you
would /not/ want garbage collection is if you want your program to be
bloated, slow, inefficient, waste memory - and leak resources, have
buffer overflows and other nasal daemons.

> 
> No, it's *still* not the way to get the best from
> most embedded hardware. It's an acceptable compromise,
> some of the time, is all that can really be said.

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

#27239

On Tue, 05 Sep 2017 14:15:23 +0200, David Brown
<david.brown@hesbynett.no> wrote:

>On 04/09/17 07:55, Clifford Heath wrote:
> 
>> Please, why don't you copy/paste all the content from
>> http://www.memorymanagement.org/
>> There might be some people here who have not read it all yet.
>> Sigh... Yes, there is a whole domain of science here.
>> Far, far more than you have reminded us of yet.
>
>I had a little look at that site.  It had some useful explanations, but
>is /seriously/ biased.  It gives the impression that the only reason you
>would /not/ want garbage collection is if you want your program to be
>bloated, slow, inefficient, waste memory - and leak resources, have
>buffer overflows and other nasal daemons.

Unfortunately, the pro-GC bias is one that is firmly rooted in
reality.

In this forum we get a distorted view because the general skill level
of embedded developers is relatively high.

In the broader programming world, the average skill level is just
slightly above "script kiddy".  The headlong march to "managed"
languages such as Java, C#, Python, etc. is industry acknowledging
that the average programmer simply can't write a complex program
without hand-holding.

And it isn't just memory management ... the runtimes of these
languages also - in whole or in part - manage files, network
connections, threads, synchronize object access, etc.

C isn't even being taught in a lot of schools now, so even those who
have a (relatively) recent CS/IS degree may have no experience of
programming that requires manual resource management.


All in all, general software development is a sorry state of affairs
that is getting worse with every passing year.  I have stated in the
past my belief that the majority of software "developers" would be
doing the world a favor by finding another occupation.

YMMV,
George

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

#27240

On 09/05/2017 09:35 AM, George Neuner wrote:
> Unfortunately, the pro-GC bias is one that is firmly rooted in
> reality.
> 
> In this forum we get a distorted view because the general skill level
> of embedded developers is relatively high.
> 
> In the broader programming world, the average skill level is just
> slightly above "script kiddy".  The headlong march to "managed"
> languages such as Java, C#, Python, etc. is industry acknowledging
> that the average programmer simply can't write a complex program
> without hand-holding.
> 

I used to write a lot of assembly.  Then I wrote a lot of C.  These days 
I write a lot of Python.  And you know what?  I get more done faster 
with fewer bugs.

Just the same as going from ASM to C, there are things that the machine 
is just better at doing than you are.  Here and there, yeah, I can sit 
there and hand-tweak better ASM than the C compiler will give me.  But 
for an entire project of any scope?  Better to let the optimizing 
compiler do 90% of the job over 100% of the project than for me to do 
100% of the job over only 20% of the project.

GC is the same thing.  Think how complicated the simple function "Create 
a new string from the concatenation of two existing strings." becomes 
when you start having worry about malloc/free.  Either:
   A) the function has to accept a pre-allocated buffer, in which case 
you've moved all the complexity of adding strlens and not getting off by 
one out of the function, making the function pointless, or
   B) the function does its own malloc, which you've now hidden under 
the hood while still forcing the caller to remember to free it at some 
point.

With GC if you need the new string, you magically create it on the heap, 
and then you walk away, comfortable in the knowledge that it'll get 
taken care of.

> And it isn't just memory management ... the runtimes of these
> languages also - in whole or in part - manage files, network
> connections, threads, synchronize object access, etc.
> 
Having tools to make the routine parts of the job easier so that you can 
concentrate on the larger problem is a good thing.

> C isn't even being taught in a lot of schools now, so even those who
> have a (relatively) recent CS/IS degree may have no experience of
> programming that requires manual resource management.
> 
> 
> All in all, general software development is a sorry state of affairs
> that is getting worse with every passing year.  I have stated in the
> past my belief that the majority of software "developers" would be
> doing the world a favor by finding another occupation.
> 
> YMMV,
> George
> 


-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

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

#27241

On 05/09/17 18:02, Rob Gaddi wrote:
> I used to write a lot of assembly.  Then I wrote a lot of C.  These days I write
> a lot of Python.  And you know what?  I get more done faster with fewer bugs.
>
> Just the same as going from ASM to C, there are things that the machine is just
> better at doing than you are.  Here and there, yeah, I can sit there and
> hand-tweak better ASM than the C compiler will give me.  But for an entire
> project of any scope?  Better to let the optimizing compiler do 90% of the job
> over 100% of the project than for me to do 100% of the job over only 20% of the
> project.

...

> Having tools to make the routine parts of the job easier so that you can
> concentrate on the larger problem is a good thing.

Yes indeed. I don't see your statements as being contentious.

Does GC solve all problems? No. (But it does solve many)

Does GC have disadvantages? Yes. (But not as many as some
people like to believe)

Are there situations where GC is contra-indicated Yes.
(But that's boring since it is true of all technologies)

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

#27265

On 05/09/17 19:02, Rob Gaddi wrote:
> On 09/05/2017 09:35 AM, George Neuner wrote:
>> Unfortunately, the pro-GC bias is one that is firmly rooted in
>> reality.
>>
>> In this forum we get a distorted view because the general skill level
>> of embedded developers is relatively high.
>>
>> In the broader programming world, the average skill level is just
>> slightly above "script kiddy".  The headlong march to "managed"
>> languages such as Java, C#, Python, etc. is industry acknowledging
>> that the average programmer simply can't write a complex program
>> without hand-holding.
>>
> 
> I used to write a lot of assembly.  Then I wrote a lot of C.  These days
> I write a lot of Python.  And you know what?  I get more done faster
> with fewer bugs.
> 
> Just the same as going from ASM to C, there are things that the machine
> is just better at doing than you are.  Here and there, yeah, I can sit
> there and hand-tweak better ASM than the C compiler will give me.  But
> for an entire project of any scope?  Better to let the optimizing
> compiler do 90% of the job over 100% of the project than for me to do
> 100% of the job over only 20% of the project.

Agreed.

> 
> GC is the same thing.  Think how complicated the simple function "Create
> a new string from the concatenation of two existing strings." becomes
> when you start having worry about malloc/free.  Either:
>   A) the function has to accept a pre-allocated buffer, in which case
> you've moved all the complexity of adding strlens and not getting off by
> one out of the function, making the function pointless, or
>   B) the function does its own malloc, which you've now hidden under the
> hood while still forcing the caller to remember to free it at some point.
> 

Anyone working in C with malloc/free for code that does a lot of string
work, is working in the wrong language.  Even though you can hide the
malloc's and frees in wrappers that make it easier to track, it is still
immensely painful - at best, you are using function-call syntax instead
of infix operators and writing code that is hard to follow.

> With GC if you need the new string, you magically create it on the heap,
> and then you walk away, comfortable in the knowledge that it'll get
> taken care of.

Garbage collection is /not/ needed for this - though it is certainly one
way to do it.  C++'s model works fine:
#include <iostream>
#include <string>
#include <stdlib.h>

using namespace std::string_literals;

int main(void) {
	auto s = "Equation: "s;
	auto t = u8"πr²"s;
	
	std::cout << (s + t + "\n");
}

No leaks, no problem using strings just like in Python, and no garbage
collection.


Of course, the C++ model has its own advantages and disadvantages, just
like the C malloc/free, and just like any given garbage collection method.


> 
>> And it isn't just memory management ... the runtimes of these
>> languages also - in whole or in part - manage files, network
>> connections, threads, synchronize object access, etc.
>>
> Having tools to make the routine parts of the job easier so that you can
> concentrate on the larger problem is a good thing.
> 
>> C isn't even being taught in a lot of schools now, so even those who
>> have a (relatively) recent CS/IS degree may have no experience of
>> programming that requires manual resource management.
>>
>>
>> All in all, general software development is a sorry state of affairs
>> that is getting worse with every passing year.  I have stated in the
>> past my belief that the majority of software "developers" would be
>> doing the world a favor by finding another occupation.
>>
>> YMMV,
>> George
>>
> 
> 

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

#27247

George Neuner <gneuner2@comcast.net> writes:
> In the broader programming world, the average skill level is just
> slightly above "script kiddy".  The headlong march to "managed"
> languages such as Java, C#, Python, etc. is industry acknowledging
> that the average programmer simply can't write a complex program
> without hand-holding.

I'm not ready to think of the Lisp pioneers who developed and used most
of today's GC techniques as "script kiddies".  Here's what
E. W. Dijkstra said about Lisp in his Turing award lecture, all the way
back in 1972:

    With a few very basic principles at its foundation, it [LISP] has
    shown a remarkable stability. Besides that, LISP has been the
    carrier for a considerable number of in a sense our most
    sophisticated computer applications. LISP has jokingly been
    described as “the most intelligent way to misuse a computer”. I
    think that description a great compliment because it transmits the
    full flavour of liberation: it has assisted a number of our most
    gifted fellow humans in thinking previously impossible thoughts.

There are certainly times when GC imposes unacceptable costs, and maybe
those times happen more in embedded programming than in other kinds of
programming.  But if the hardware can accomodate it and it helps do the
job faster, why would anyone not use it?  

I worked on a thing a few years ago that had around $50K of software NRE
(Python) and used $300 worth of hardware including two ARM processors.
By writing it in C maybe we could have spent $10 less per hardware unit,
but at least 3x more on programming, plus the time-to-market delay, loss
of feature flexibility, etc.  We'd have to ship quite a lot of units to
even think of switching to that approach.  And I think it would have
been silly to use C from the beginning, instead of using it for an
eventual cost reduction once we had gotten experience from multiple
generations of fielded units programmed in Python.

Obviously not all situations are like that.  But I think it is getting
more and more typical.

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

#27264

On 05/09/17 18:35, George Neuner wrote:
> On Tue, 05 Sep 2017 14:15:23 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
> 
>> On 04/09/17 07:55, Clifford Heath wrote:
>>
>>> Please, why don't you copy/paste all the content from
>>> http://www.memorymanagement.org/
>>> There might be some people here who have not read it all yet.
>>> Sigh... Yes, there is a whole domain of science here.
>>> Far, far more than you have reminded us of yet.
>>
>> I had a little look at that site.  It had some useful explanations, but
>> is /seriously/ biased.  It gives the impression that the only reason you
>> would /not/ want garbage collection is if you want your program to be
>> bloated, slow, inefficient, waste memory - and leak resources, have
>> buffer overflows and other nasal daemons.
> 
> Unfortunately, the pro-GC bias is one that is firmly rooted in
> reality.
> 

Garbage collection certainly has its advantages - but equally it is not
a magic wand that solves all memory problems, nor is it the right tool
in all situations.

> In this forum we get a distorted view because the general skill level
> of embedded developers is relatively high.
> 

True.

And we also tend to avoid dynamic memory as much as possible!

> In the broader programming world, the average skill level is just
> slightly above "script kiddy".  The headlong march to "managed"
> languages such as Java, C#, Python, etc. is industry acknowledging
> that the average programmer simply can't write a complex program
> without hand-holding.

On PC's, I usually write in Python - and the automatic memory management
is one of the nice things about the language.  In that context, I
absolutely agree that automatic memory management and garbage collection
is the right way to go.

My point is just that there are other situations, other types of
programming - and other solutions.  The website there was written like a
marketing campaign rather than an unbiased reference.  As well as
dismissing C-style memory management out of hand, it described C++'s
methods as "even harder" with no basis whatsoever (RAII and synchronous
destructors makes memory management far easier) and pretty much ignored
smart pointers altogether.

It also ignores the problems of garbage collection.  In particular, it
is very easy to get circular references in complex structures, and it is
easy to get memory leaks in garbage collected systems.  Garbage
collection makes the issues of memory management different - it is not a
magic fix-all solution.  It lets you avoid the micro-managing and write
simpler code, but it does not fix everything.  It just teaches a
generation of programmers that it does not matter if your Python program
leaks 100K memory an hour - that's only a GB a year, and everyone has
gigabytes to spare.

> 
> And it isn't just memory management ... the runtimes of these
> languages also - in whole or in part - manage files, network
> connections, threads, synchronize object access, etc.

They do indeed - but that is a process that is mostly independent of
garbage collection.  The only direct connection is that by making your
clean-up happen asynchronously and behind the scenes, you have lost
control of where your tidy-up is done.  With C++, your file will be
closed by the file object's destructor.  That means your code that
/uses/ the file object does not need to have the close file logic, but
you know the file will be properly closed when the using function exits
by return or exception.  With a garbage collected language, you have the
choice of manually putting in the "close" call in your using function,
carefully catering for try/except/finally blocks to make sure it is
handled in exceptions, or you put it in the object's finaliser to be run
eventually, at an unknown time in an unknown order.

For Python (as the gc'ed language I use most), you just assume it will
all be tidied up sooner or later.  It works because garbage collection
runs regularly so it won't be /too/ long before the destructor is called.

> 
> C isn't even being taught in a lot of schools now, so even those who
> have a (relatively) recent CS/IS degree may have no experience of
> programming that requires manual resource management.
> 
> 
> All in all, general software development is a sorry state of affairs
> that is getting worse with every passing year.  I have stated in the
> past my belief that the majority of software "developers" would be
> doing the world a favor by finding another occupation.
> 

I certainly think that most people who program in C, should be using
other languages.  And most programs that are written in C, would be
better written in other languages.  (Embedded development is major
exception, though even here there are alternatives.)  And the memory
management in C is a big reason for that opinion.

But telling people that garbage collection is always the best choice and
that it solves all memory and resource problems, is not the answer.
It's like saying if you buy a car with automatic gears, collision
detection with automatic breaking, etc., then you don't need to learn to
drive properly.

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

#27246

David Brown <david.brown@hesbynett.no> writes:
>> http://www.memorymanagement.org/
> I had a little look at that site.  It had some useful explanations, but
> is /seriously/ biased.  ...

You might look at

  https://www.cs.kent.ac.uk/people/staff/rej/gc.html

I've seen the 2011 book and it is great.

Hans Boehm also has some good GC pages.

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

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

Back to top | Article view | comp.arch.embedded

csiph-web