Go Down

Topic: post-UNO world of 32-bit uC's with 20K or more of SRAM (Read 2491 times) previous topic - next topic

-dev

Quote from: Robin2
I was not trying to suggest...
Right, I didn't think you were.  I probably should have emphasized this:

   "You could write..

Fixed above.

Quote
I was trying to get your opinion about the "safety" of using languages that have in-built GC on a PC?
Well, the word "safety" can trigger all kinds of requirements, so let's just say "risk of slowing down over time."  The answer is that, just like when using malloc/free, it isn't difficult to write code that makes it hard or impossible for a GC to do its job.  With some care you can mitigate the risk.  Anything that gets "deployed" and that could have "serious" consequences will/should be reviewed and profiled to catch the naughty behavior.  Most software doesn't go through that process, so you can expect most software to exhibit the problem.  Empirically, slowdowns obviously happen and it's not because electrons are tired.  ;)

Cheers,
/dev
Really, I used to be /dev.  :(

Robin2

Well, the word "safety" can trigger all kinds of requirements, so let's just say "risk of slowing down over time."  The answer is that, just like when using malloc/free, it isn't difficult to write code that makes it hard or impossible for a GC to do its job.  With some care you can mitigate the risk.  Anything that gets "deployed" and that could have "serious" consequences will/should be reviewed and profiled to catch the naughty behavior.  Most software doesn't go through that process, so you can expect most software to exhibit the problem.  Empirically, slowdowns obviously happen and it's not because electrons are tired.  ;)
A good "politician's" answer. The only part you missed was the preamble "I'm glad you asked me that question" :)

I was not trying to enquire whether it might be possible to defeat a garbage collection system.

I just want to know if a person can write a program using (for example) one of the .NET languages or Python or Ruby or Java without having to worry about memory leaks due to poor garbage collection?

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

-dev

Quote
I just want to know if a person can write a program using (for example) one of the .NET languages or Python or Ruby or Java without having to worry about memory leaks due to poor garbage collection?
Hmm...  It's a broad question, so I'm having trouble giving a narrow answer.  The narrowest things I can say are:

*  All the platforms listed have good, tested GCs.  If you are careful, they should be able to "find" things that should be deleted, which keeps the memory footprint down.

*  GCs do not prevent fragmentation, except as a secondary effect of freeing memory.  I'm sure those platforms use many advanced techniques to avoid fragmentation for the most common resources.  For the .NET framework, MSDN explicitly states: "Virtual address space can get fragmented."

*  It is not difficult to write code that defeats GC, and I don't mean maliciously.  Beginners can write naive code that will cause a slowdown due to fragmentation and/or swapping due to increasing memory usage.

*  It is easy to write code that has unbounded memory growth.  Experienced developers can do it accidentally.  Remember the recent forum slowdown?  It was caused by an array that was getting too large.  :D  And have you ever seen a sketch that limits the size of a String?  Use that "+=" with abandon!

So.  Can "a person" write "an app" on those platforms, using "dynamic objects", still achieve bounded memory growth, bounded fragmentation, and long-term stability (days)?

Yes, it is possible.  But in a random sample, I would say the odds are "not good".  Just consider the size of those platforms, the impossibility of being idiot-proof, and how often EVERYONE HAS TO REBOOT.

To narrow it down any further, you'd have to get more specific:

*  Does the app use just the core components of these platforms, or did it incorporate libraries from "someone".

*  Does the app create and destroy dynamic objects?

*  What is the expertise of "a person"?

*  Does "a person" know how to measure the memory footprint?

*  Does "a person" know how to measure the response time?

With all these considerations in a desktop environment, where GBs of RAM and virtual memory are available, I would never recommend using String on an Arduino with a whopping 100KB RAM, to anyone: the beginner does not understand the consequences nor recognize the symptoms, and the expert already knows the dangers and has probably decided to use something less fragile, more predictable and more efficient.

Cheers,
/dev
Really, I used to be /dev.  :(

Robin2

A comprehensive answer. Thank you.

And, at the end, nicely linked to the Arduino system.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

mrburnette

A comprehensive answer. Thank you.

And, at the end, nicely linked to the Arduino system.

...R
/dev makes great sense for the "hardliner" view by the embedded programmer... just do not allocate objects on the heap.

But IMO one or two examples from the Arduino world on how a couple of folks have gotten tangled up with Strings is no excuse from completely dismissing the entire Class.

I again go back to the fact that the Arduino String object is used often with the ESP8266 and there are few reported issues.  The entire Teensy forum only has a couple of spin-crash-burn examples - but there are many, many more success stories.

Paul Stoffregen, designer of the Teensy and owner of PJRC.com, completely reworte WString.h and WString.cpp years ago and that code is used verbatim in igrr's implementation of the ESP8266 core files located here.

When Paul was asked last year about the String class he said,
Quote
Yes, if you're philosophically ok with heap-based memory allocation, String works fine.

For cases where you incrementally increase the length of a String, the reserve() function lets you pre-allocate the memory, which is far more efficient and often avoids memory fragmentation issues.
That was a year ago and I have found no implementation changes since that post.

Paul is a competitor to the Arduino hardware line and I hardly think he would implement software that would be detrimental to using his products... he is a professional programmer and could have chosen to just leave out the entire String class if he had wanted and shown his forum how to professionally work around the issues.  But, that is not what he is doing.

I'm going to consider this discussion a religious argument akin to the GOTO argument often used in C/C++ ... the language supports goto but the philosophical hardliners curse anyone that would dare to use it.  Yet, assembly programmers use goto all the time!

My advise to 32-bit Arduino folk is to use String but use it carefully. 

/dev has given some excellent references for understanding the hardline concerns.  But concerns do not always materialize in poor coding and poor coding does not always promote broken code.  The String class was implemented by Arduino.cc because it is useful.
The code was long-ago rewritten by Paul Stoffregen to work correctly as the Arduino architects originally intended.  Teensy users use the String class and ESP8266 users use the String class...  It is not perfect because it can be so easy to use that some new programmers may abuse it.  You have been warned.  Sometimes you just need to try something for yourself and see if it works for you ...

Ray




Go Up