Since debugging and testing may also require more resources than are available on the BeagleBone Black, cross-compilation can be less involved and less prone to errors than native compilation.
Thank you for replying.
BBB has limited resources to make build and install R packages (R-base and some ML packages, or any other packages for that matter). Also, I would like to test the build before actually porting the binaries to BBB. Since debugging and testing may also require more resources than are available on the BeagleBone Black, cross-compilation can be less involved and less prone to errors than native compilation.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
@William
Thanks for clarifying in detail. Yes, I have checked that the Python code
written in x86 can be run on ARM system by just copying the code.
There are certain barriers as you pointed out, like slow compiling and limited RAM size.
In my algorithm, I have to deal with a continuous data stream so limited ram size may affect the
computation heavily. And, fast computation of large dataset is badly needed in my algorithm.
That is why, I was thinking about cross-compiling.
And also, as you suggested to use swap drive like virtual memory concept,
can you elaborate on how to implement it?
Seriously, Javascript in the context of googles V8 engine ( Nodejs ) really is that fast. However, one thing I have noticed personally. Nodejs, when written to run as a command line executable does have noticeable latency. Meaning, if you need a tool that executes once when run, and then it exists. Nodejs probably is not the best tool for that type of Job. If the code is run once, and runs for long periods of time however . . . Nodejs will perform really well. Still not as fast as C, and depending on what the code is doing, perhaps not as fast as C++ either.
Anyway, C is probably the best well known for being the universal embedded language of choice for many embedded developers. So perhaps you may want to consider which language you use. C++ is also making it's way into many embedded projects. On a personal note however, I think C++ is a great language especially when it comes to generics, and templates. However because of all this "coolness" C++ brings it also bring complexity with it. So for me personally, I tend to stick with straight C whenever possible. Which has worked out to always for me.
@William, please do share your blog site when you will
finish writing the guide. That will be a great help.
--
The OP said he has algorithms already written in Python so I was pointing out that if he need to improve performance, it is easy to do. Anyway, you know that most build systems like Openembedded, yocto, etc, all use Python? If it was so slow, they wouldn’t be using it. Now I’m wondering why they just don’t write the whole thing in C ;-)
Regards,
JohnI kind of like the idea behind interfaces in C for Python . . . I just don't like Python. So John, if you read my posts above you'd know that I know that Python is a requirement for building Linux systems. Python Perl, and C are all required. I said "Ruby" above, but meant Perl. In my mind they're both equivalent( garbage, but useful I guess ), hence my mistake Anyway . . .