Another thing to point out, that I forgot to mention in my last post. Depending on what you're doing with said code, Python can be dog slow. When compared to many other languages for several situations. Performance wise, Python is way down the list. I only mention this, as it seems to me that you have a performance constraint for your situation. R I would assume will not be much better, but possibly better than Python. Honestly 99% of the other languages out there will outperform Python in many cases.
So, if you really need performance, you're probably going to want to use another language. But to put things in order . . . 1. Assembly 2. C 3. Sometimes C++ Sometimes Javascript ( V8 engine ). 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. On Tue, Feb 16, 2016 at 2:15 PM, William Hermans <[email protected]> wrote: > *@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.* >> > > Ok, so what you need to understand. Is that a run-time is just an > abstraction layer. It's this abstraction layer that handles all the system > level gory details. So once it is in place, everything else being equal, > it'll "just work" As Robert eluded to however, and I think I also mentioned > in my last post. Compiler / run-time versions need to be the same, or very > close for the best results. > > *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.* >> > > So, compilers, toolchains etc are getting very complex now days. Sometime, > just setting up a cross compile system for a certain situation can take a > considerable amount of time. So one needs to weight this possibility > against how long it might actually take to compile natively. If neither > possibility is acceptable, then one should look into buying a "bigger and > better" system to use as a build system for the beaglebone. It's been done, > and is what is refereed to as solving a problem by "throwing" more money at > the problem. A perfectly acceptable practice, for some. > > >> *And also, as you suggested to use swap drive like virtual memory >> concept, can you elaborate on how to implement it?* >> > > This is something I would have to write a guide for, and put up on my blog > site, and which I might actually do soon. The problem here is that because > this is not a PC type computer system. The guides for that on the internet > will not work for this situation. These guides can be modified . . . but it > can be complex. Better for me to write and test a guide I know that will > work. One thing to keep in mind however. The USB drive has to has it's own > power supply. As the beaglebone will not supply enough power for the drive, > especially at "spin up". Where some drives can draw as much as 3A . . . > > On Tue, Feb 16, 2016 at 1:56 PM, Robert Nelson <[email protected]> > wrote: > >> On Tue, Feb 16, 2016 at 2:51 PM, <[email protected]> wrote: >> > @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. >> >> "cross-compiling" isn't going to help you there, as you still need to >> run your "algorithm" on the ARM system right??? >> >> In the end, native vs cross building should give you the same final >> binary (assuming your cross/native compilers are the same >> version/etc..) >> >> Regards, >> >> -- >> Robert Nelson >> https://rcn-ee.com/ >> >> -- >> 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 [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
