Project "Beyond"

All things embedded.
*NO FEATURE REQUESTS*

Re: Project "Beyond"

Postby krisp » Wed Nov 22, 2017 12:35 pm

Watching very closely. How awesome would that be to have a higher bitrate for D3300. Thanks for your great work! K.
krisp
 
Posts: 1
Joined: Wed Nov 22, 2017 12:26 pm
Been thanked: 0 time

Re: Project "Beyond"

Postby Mindstrm » Tue Nov 28, 2017 10:33 pm

Very interesting indeed as the D7200 has to share practically everything with the D7100 right?? Asking for a friend ;)
Mindstrm
 
Posts: 1
Joined: Tue Nov 28, 2017 10:30 pm
Been thanked: 0 time

Re: Project "Beyond"

Postby coderat » Mon Apr 16, 2018 7:54 am

This project showed up that simulating of multi-core system is only possible by real multi-core emulator. My first idea was to have one core emulator and manipulate tasks to run on one core only. I failed the whole way on spin locks. Spin lock is a lock where task is busy waiting for resource. The firmware is full of them. Busy waiting at certain priority level blocks other tasks from execution. It showed up that it results in forever waiting. So I dropped this idea.

Next idea was to simulate really several cores. After implementation it seems to be working. At the moment 2x ARM cores are really simulated for D7100. However, the price was enormous performance drop by factor 2x. Newer cameras employ even more cores, so performance gap will grow further. That results in very slowly emulation on one side and Java problems with memory management on another side (that seems to be a limit of 2 GB and java 7 reaches it pretty fast resulting in huge drop of performance due garbage collection afterwards).

So new ideas must be tested for Project "Beyond"...
coderat
Core Developer
 
Posts: 2278
Joined: Fri Apr 26, 2013 10:21 am
Been thanked: 450 times

Re: Project "Beyond"

Postby Simeon » Wed Apr 18, 2018 2:03 am

so ether it needs to have a core written in something faster (C++/Rust?) and/or something that uses 64bit memory spaces (C#) and/or reduce dynamic object creation, and use more static memory model.. to be fair I was always biased against Java, but the screen shots you have shared are all the same impressive..
Simeon
Core Developer
 
Posts: 2606
Joined: Wed Nov 30, 2011 6:12 am
Location: Christchurch, New Zealand
Been thanked: 613 times

Re: Project "Beyond"

Postby coderat » Thu May 03, 2018 8:27 am

I guess decision for Java was primarily because Vicne programs in Java.

As for me, lessons learned:
  • Java memory allocation schema and garbage collector waste a lot of memory. Emulator hits easily 1GB and more, for example emulating D5100.
    The most disappointed thing is that "local object/variable" in function is not really local in Java! In C++ objects/variables from function local scope like std::string are destroyed at the end and resources are freed. At the end 0 memory used. In Java I had to move some StringBuffer from function local scope to class global scope, otherwise JVM eats all RAM available and ends with message about low memory. But this restriction is completely stupid and makes difficult to implement many things !
  • Java doesn't scale well to 64-bit: with server edition seems only 2.8 GB are usable. That is strange nowadays: many notebooks have 8GB RAM and more !

IMHO Java is a bad choice for such applications like Nikon Emulator.
coderat
Core Developer
 
Posts: 2278
Joined: Fri Apr 26, 2013 10:21 am
Been thanked: 450 times

Re: Project "Beyond"

Postby coderat » Thu May 10, 2018 8:22 am

Next try...
Attachments
screenshort23.png
coderat
Core Developer
 
Posts: 2278
Joined: Fri Apr 26, 2013 10:21 am
Been thanked: 450 times

Re: Project "Beyond"

Postby Vicne » Sun May 13, 2018 12:42 pm

(I'm not really present, just passing by...)

coderat wrote:I guess decision for Java was primarily because Vicne programs in Java.

Yep :-). I never claimed it was the best, just that it was feasible and that my C skills sucked...

However...

As for me, lessons learned:
  • Java memory allocation schema and garbage collector waste a lot of memory. Emulator hits easily 1GB and more, for example emulating D5100.

Java by default it is quite lazy in releasing memory. However, the Garbage Collection strategy can be tuned very precisely with command line params passed to the java VM, but generally speaking, that's a trade off: either the CPU spends much time performing GC and keeps memory low, or the app is focused on performance at the cost of using more memory. See for example https://www.cubrid.org/blog/how-to-tune ... ollection/
Please also note that when writing the emulator, I often opted for performance at the cost of memory. e.g when any byte is read or written in memory by the camera code, the 64k block it contains is allocated and never returned. If a process scans random bytes in memory, 4GB of RAM (in the old architecture) will be reserved, and never freed.

The most disappointed thing is that "local object/variable" in function is not really local in Java! In C++ objects/variables from function local scope like std::string are destroyed at the end and resources are freed. At the end 0 memory used. In Java I had to move some StringBuffer from function local scope to class global scope, otherwise JVM eats all RAM available and ends with message about low memory. But this restriction is completely stupid and makes difficult to implement many things !

Hmm, that's the whole point of Garbage Collection. C/C++ uses strict memory allocation where every allocation has a symmetric free operation, be it performed by the compiler for static memory (as in a local variable case) or by the programmer for dynamic memory (malloc/free or equivalent).
C# also uses Garbage Collection and works the same AFAIK: https://docs.microsoft.com/en-us/dotnet ... ollection/
However, the memory allocated for local variables is not lost upon exiting a Java/C# method. It's just considered "garbage" and will be recycled when the Garbage Collection process starts. That "when" is determined by the tuning params (see above). Note that the programmer can also trigger Garbage Collection by calling System.gc() if he knows that it's the right time to do so (e.g. before performing a time-critical operation).

  • Java doesn't scale well to 64-bit: with server edition seems only 2.8 GB are usable. That is strange nowadays: many notebooks have 8GB RAM and more !


Err, no, Java has no such limitation. Some people run JVMsusing 32GB ram or more and I run several servers with 8GB or 12GB VMs on a daily basis. With a 64-bit JVM on a 64bit OS the theoretic limit is 16384 Petabytes.
It's just that by default, a VM restricts itself to a certain memory size because it wants to play nice with the OS and other processes running on the same machine.
That limitation can be lifted too by tuning command line parameters, the most useful one being "-Xmx". If the code throws a java.lang.OutOfMemoryError, try modifying the batch file that lauches the Emulator, and modify (or add) the option so that it reads -Xmx6G (or -Xmx6144M) for example to allow the VM to use up to 6 GB Ram. Similarly, if your observations show that the app usually requires a minimum of 2GB, you might want to reserve a contiguous 2GB block right from the start by adding the -Xms2G (or -Xms2048M) param.

Note that manual tuning and finding memory hogs in code can be made easier with the free "Java VisualVM" tool which can monitor a running app (threads, performance, memory, etc.) - https://developers.redhat.com/blog/2014 ... plication/

IMHO Java is a bad choice for such applications like Nikon Emulator.

Probably going further in Java is a bad choice if you're more fluent in C/C++ indeed.
If you're happy with C#, hopefully converting would be quite straightforward for the "core" emulation and disassembly because it's quite basic language and changes would mostly be cosmetic. Probably the UI would be the hardest :-(
If you want to go to C++, it will probably be much more work.
And if you target plain C, then probably rewriting everything from the ground up will be faster and cleaner, due to the strongly object oriented structure...

It's nice to see the great work you have done and are still doing. Don't hesitate to post the sources... "given enough eyeballs, all bugs are shallow".

Cheers to all ;-)

Vicne
Vicne
Core Developer
 
Posts: 1730
Joined: Tue Nov 29, 2011 2:30 pm
Been thanked: 167 times

Re: Project "Beyond"

Postby coderat » Mon May 14, 2018 2:05 pm

Java was mean to free programmer from garbage collection. It works may be for some applications, but not for all.
According to Oracle paper Java7 can't utilize more than 3GB on 64-bit. I tried and didn't get more.

Discovered Emulator problems by me are related to disassembler in first place. Sequential algo disassembling 16MB ARM firmware hits 1GB memory usage and (after hard attempts) no way to fix without giving up OOP or reducing performance by >100x.
And firmware grows and disassembler badly need more features.
=> Java is bad choice for such jobs.

P.S. Seems functional language elements like local variables, lambdas, etc is a big challenge for GC-based Java language.
coderat
Core Developer
 
Posts: 2278
Joined: Fri Apr 26, 2013 10:21 am
Been thanked: 450 times

Re: Project "Beyond"

Postby maxracingshox » Tue May 15, 2018 4:51 am

Wow, I really admire the skills you guys have. I'm excited to see if there will be some hack for the d7200 some day :)
maxracingshox
 
Posts: 6
Joined: Tue Sep 05, 2017 12:43 am
Been thanked: 2 times

Re: Project "Beyond"

Postby Vicne » Tue May 15, 2018 1:49 pm

coderat wrote:Java is bad choice for such jobs.


Agreed.
I'm glad you took over because I really can't code in C++ and this project really deserves it.
Can't wait to see your code and test it !

All the best !

Vicne

PS: I'd be interested to read that Oracle paper though... The 3GB barrier on 32-bit is well known, but using a 64-bit JVM, never heard of it...
2018-05-16_0037.png
Ram tester
Vicne
Core Developer
 
Posts: 1730
Joined: Tue Nov 29, 2011 2:30 pm
Been thanked: 167 times

PreviousNext

Return to Firmware

Who is online

Users browsing this forum: No registered users and 3 guests

cron