If I write a program in C++CLI / managed C++, does the compiler perform any optimizations?
I know that for C#, there are some optimizations done at compile time, with most optimizations being done by the JIT. Is the same true for C++CLI?
A similar question: can I do the equivalent of an -O2 flag, for C++CLI? I already know about the "-c Release" flag, but I'm unclear on what kind of optimizations it does.
Thanks!
C++/CLI code is always optimized in the Release build, yes. By whom is the key, you can freely mix as you dare. This tends to go wrong with too much native C++ code getting compiled to MSIL. Hard to notice, the code generator can handle any compliant C++03 code and rarely squeals about any C++1x incantations.
A good reminder that the jitter isn't that much different from a C++ compiler's back-end. MSIL compares pretty well to, say, the IR that LLVM needs. The IR that the MSVC++ compiler uses for native code isn't documented and not visible.
Which makes it a good practice to isolate the native C++ you wrap in its own static library or DLL. But mixing at the function-level is possible, you can switch back-and-forth with #pragma un/managed.
So it is much like you'd guess, #pragma unmanaged code gets the full optimizer love and #pragma managed gets optimized at runtime by the jitter. You'll find jitter optimizations documented in this post.
When generating native code, the C++/CLI compiler supports the same optimizations as Microsoft's native C++ compiler.
When generating MSIL, the C++/CLI compiler supports a smaller number of optimizations (but still more than C#), and then another optimization pass takes place during JIT (same JIT and same JIT-time optimizations as apply to C#).
For example, loop unrolling is possible when generating MSIL, but auto-vectorization is not, because MSIL doesn't have SIMD instructions. Vectorization may theoretically still be done by the JIT, but in practice the resource constraints of a JIT mean that optimization is less effective.
In addition, there are some optimizations possible for C++ but not C# due to language design. For example, C++ templates (including in C++/CLI) are compiled for each combination of template arguments, while .NET generics (including in C# and in C++/CLI) are fully resolved only based on the generic constraints.
Related
I am trying to build a mac(cocoa) app. I have a framework that I am trying to link with that has been compiled for iOS(the armv7 arch). I unfortunately no longer have the source code that I used to compile the original framework. Would it be possible to change the architecture of the framework(perhaps through decompilation and then recompilation) so that it can be compiled into my cocoa app?
So far I have looked into lipo and fat binaries as well as using optool to decompile but haven't made any direct progress towards converting architectures.
Thanks for your help.
No, there is no reasonable way to automate this conversion. Most C decompilers generate code that is a very literal translation of the assembly; it is usually not suitable for compilation.
(One good decompiler is the Hex-Rays plugin for IDA Pro. However, it is extremely expensive -- a license is over $2000. Unless your framework is particularly large and complex, it may be more cost-effective to work without this tool.)
If you have really lost the source code, your only real option will be to rewrite the framework. You can use the disassembly to guide your efforts, but you will need to fill in some of the details.
In theory, if the code doesn't use any POSIX system calls directly, it might be possible to create an Frankensteinian abomination:
Run the code on an arm64 emulator.
Replace all function call linkages into the Objective-C runtime (e.g. objc_msgsend) with emulator traps.
Abort if you find any other function call linkages.
For runtime function calls, call the equivalent runtime function on the x86-64 side.
For alloc calls, return an NSProxy object on the arm64 side that traps into the emulator.
For any objects passed via parameters, return values, or return parameters, pass an NSProxy object.
That said, in practice, unless the framework is insanely complex, it would be faster to rewrite the code. And realistically, even if it is insanely complex, if you know enough arm64 asm to pull this off, you can probably rewrite it from the asm more quickly. :-)
I know that scripting languages don't use a compiler but rather are interpreted. But I can't find information why exactly is it beneficial? What do they gain by being interpreted?
the positives -
easier to create as they piggyback on an existing code system (c/cpp)
syntax easier to work with in most cases as the creators can focus on that rather than writing a compiler.
drawbacks:
need to provide the runtime package to use the code as it's not compiled down to native machine code. (it's instead interpreted into c functions, need the runtime to referee this)
not quote as fast as running native machine code
Scripting languages are designed to be interpreted. They are executed sequentially and the source itself is executed. Compare to something like C++ where a compile and link phase are fundamental to the language itself, and by the time you execute it, the source code is long gone.
So the default position is to interpret scripting languages. Interpreters may even compile in the background for optimization purposes.
So what are the advantages of interpretation versus compilation?
Simpler development environment. No compile process vastly simplifies development. Scripting languages don't require the effort of establishing a whole development environment.
Scripting languages can be used in small chunks - for example inline script in a webpage, or a little event handler in an application plugin. C code for example does not stand alone in small chunks like this.
There are lots of oop languages, but I couldn't find any that has conveniences like garbage collection, but compiles natively to machine code. Sort of like between C and java/c#. One interesting language I found was Vala, but that's limited to the GNOME platform and is not that well-known
Go is probably closest.
But why on earth do you want it natively compiled anyway?
JIT compilation of portable bytecode has proved to be an extremely effective strategy. It compiles down to native code at runtime (so you get up to the performance of native code after the first few iterations) and it avoids the issues of having to build and manage platform-specific compiled binaries.
Are you thinking about C++? That is in high usage and can be compiled on nearly any (major) platform.
In the case you want to use an oo language that compiles down to native code you will "always" have to use header files and stuff as the elf format doesn't support oo (There is no class information in elf).In case you want to use classes from external libs you need to make the compiler aware somehow about the fact that there are classes, functions, etc. that are declared outside of your project. In C++ this is solved by the use of header files. So that's, I think, a major drawback in native object oriented languages. To resolve that issue a few tweaks would need to be made to elf/loader/linker in order to support the kind of features (like "linking" against "classes") you might expect. Even though mechanism for garbage collection could be implemented even in native languages. But that seems no good for os implementation.
There are C++ libs to do that for userspace apps like:
Boehm collector
Smart pointers
The thinking is that since variadic templates are a compile time feature, there will be little ABI impact or runtime behaviour change. Is this possible?
I specifically want the benefit of faster compile times for boost::mpl::vector and boost::mpl::string.
Rephrasing the question...
Is it possible to mix c++03 and c++11 code by separating them into libraries? I.e. we use quite a few 3rd party c++ libraries which are compatible with gcc 4.3 but we are moving on too gcc 4.7 and intend to use c++11 features where possible/makes sense. Or is it impossible to mix c++11 and c++03?
You should compile and link everything using the same tools running in compatible modes. You can't cherry-pick features like this.
The ABI impact comes in, for example, increased virtual function tables for standard I/O classes. It is not safe to mix things around.
I cant give a qualified answer, but from what I understood is, that lots of people would be concerned if this kind of backward-compatibility would be broken. As far as I understood there is nothing in the new C++11 that makes it necessary to rebuild everything. Thus, it could only be your specific compiler that would make that necessary. For the GCC I dont't expect it, although, the different libstdc++ versions could create "issues".
My strong guess is, that on a typical (intel-) linuxes you should be able to create two independent libs with different decently new versions of the gcc (maybe >4.x) and use/link them into a final program. You may have some things in there twice, though. I had some minor solvable issues with threads in 4.7.0 and <thread>. I don't know if they would create a good or bad mix with other thread-libs (eg. boost). However, you don't want to use gcc-4.7.0 for your production code, yet. And before a final gcc compiler is out, only a statement from the responsible projects team can give you certainty.
I was confused as to what is the difference between a Script and a Program, but a previously asked question Difference between a script and a program? clarified my doubt but that further leads me to wonder what is the difference between an Object being Scriptable versus being Programmable.
Not sure if this is what you're looking for but scripts are generally interpreted at runtime by another program which does something meaningful, whereas programs are typically executable directly on top of the CPU because they were compiled to assembly.
Notable exceptions are .NET managed languages and Java, which 'compile' to IL and bytecode and need some kind of runtime (CLR, JVM, DVM) to execute.
As noted by Michael Petrotta in the question you reference, scripts are generally interpreted and slowish , programs are generally compiled and fasterish. Compiled is often faster than intepreted because interpretation includes compilation at run time (vague and not always the case, but good enough).
Scriptable, to me, means that the object in question supports the interfaces required to be accessable from one or more script languages (for example, JavaScript and/or VBScript).
Programmable, to me, means that the object in question supports the interfaces required to be accessable from a programming language (for example, C++ or Java).
Interpreted and Compiled languages are all programming languages so it is all programming.
Summary: Scriptable vs Programmable are two vaguely synonomous terms.