Caret5/Caret6/Caret7 pros and cons

From Van Essen Lab

Jump to: navigation, search

Problems:

  • Duplication of effort due to caret_command in C++ and Workbench in Java. (CIFTI and NIFTI files, algorithms, and other overlap).
  • Java portability issues, especially on Linux with Windowing and OpenGL.
  • Java array size limitation.
  • Java memory usage.
  • The choice is not Caret5 (C++) vs Caret6 (Java). It is Caret6 (Java) vs Caret7 (C++ based off Caret6 architecture). Note that Caret6 is multi-structure and does not support every file format in the world.

C++:

  • C++ uses less memory. At startup without loading any files, Caret5 uses 40MB and Caret6 uses 1.1GB. After loading similar data files Caret5 uses 151MB and Caret6 uses 1.7GB.
  • STL containers can be hard to debug.
  • Better runtime performance.
  • Third party libraries are difficult to configure and compile.
  • Standard library not well documented.
  • If C++ crashes, just get "segmentation fault".
  • Development environments not as 'smart' as Java IDEs.
  • Compiling takes too long (eliminating 3rd party libraries and using LLVM compiler may help).
  • Unique executable for each platform and 32/64 bit (though 32 bit may not be needed much longer).
  • Separate header/implementation files are an inconvenience.
  • OpenMP simpler than Java or C++ threads.

Java:

  • Compiles very fast.
  • Syntax checking occurs while editing.
  • Easy to profile and debug.
  • Do not need to recompile for debug/release/profiling.
  • Framework provides GUI, Network, etc and very well documented.
  • Porting to Linux has been problematic, in particular OpenGL and some windows behavior.
  • Strong error checking such as array bounds.
  • Will never run on iPad/iPhone.
  • Compile once, run on multiple platforms.
  • Crash produces a call stack with information about the error.
  • OpenGL support is not part of standard Java.
  • Garbage collection (but can slow runtime).
  • Swing (GUI) sort of sucks. Just seems "not finished" and poor layout managers.
  • Logging system.
  • Single file (no separate header/implementation).
  • Arrays cannot contain more than 2,147,483,647 (46341 ^ 2) elements (less than number of elements in some dense connectomes).
  • SumsDB is Java and has issues using C++.

WebGL

  • Security issues have arisen since WebGL allows low level access to graphics card.
  • Apple seems to be in no rush to place it in official versions of Safari on OS X or iOS.

If Caret7:

JKS's approach to Caret7 (or caret5):

  • Don't do a rewrite from scratch, as this will take too long. Come up with a strategy for refactoring Caret5 incrementally.
  • Prioritize the list of items above, don't try to do them all at once.
  • Things like fixing design issues are part of the maintenance of software, not just something that you do once in the beginning and forget about. A permanent fix for what ails us in Caret5 is not to rewrite, but to start fixing issues in our software regularly rather than letting problems pile up.
  • I think very little of the items listed under Caret7 (above) are actually needed to fix the issues in Caret5, much less to bring Caret5 up to functional parity with Caret6. Our biggest design issues are:
  1. The design of our file IO library, it's too monolithic.
  2. The overall design of Caret is also too monolithic.
  3. 3rd party libraries aren't the problem, it's our reliance on our own builds for them that is the issue. Also, circular dependencies (i.e. libraries are interdependent, rather than having a hierarchical separation of responsibilities) means that a change in one part of the software requires everything to be rebuilt.
  4. Modules should have clearly defined interfaces. Modules should never have circular dependencies, instead, division of responsibility should follow a clear hierarchy, with base classes knowing nothing about the things that inherit from them, and utility libraries knowing nothing about the code that uses them.
  • To get Caret5 up to speed with Caret6, we need to do the following:
  1. Implement Connectivity Selector in Caret5
  2. Implement support for caret6 spec and GIFTI file format in Caret5
  3. Implement support for viewing two hemispheres at once
  4. Implement support for reading from ConnectomeDB
  • I don't think that using the latest language features or dogmatically following coding standards is a replacement for regular software maintenance. Caret5 used quite a bit of advanced C++ features, but it's issue is that some issues have been allowed to remain. Spending a bunch of time on a complete rewrite won't fix this.
Personal tools
Sums Database