The documentation for SymEnumSymbolsEx() reads:
SYMENUM_OPTIONS_DEFAULT 1 Use the default options.
SYMENUM_OPTIONS_INLINE 2 Enumerate inline symbols.
What are "inline symbols"? What do SymFromInlineContext and the other inline procedures do?
You should know about inline function:
The function code is expanded at the point of the call at compile time which will save the overhead of a function call. So it doesn't look like a "real function call", Similar to macros function. However, different with macros function, it also has a symbol link.
Related
I am trying to understand the preprocessor directives (like #if , #ifdef, #ifndef) and following is the code I have tried out.
Note: The member functions are further wrapped and used in python and hence the results show the python like calls but this does not affect any of the c++ process.
Question: 1. As per my understanding the global variables have a scope of whole file from the point it is declared. Then in this case, why is the defined value not accepted inside another function?
Requirement: I want to do something like mentioned below:
void Somefunc(int val){
set variable x;
}
Based on the x value, I want to include functions. Now the condition is:
If x=1, only some functions should be compiled since others utilize headers which would throw errors with the compiler I am using.
Thanks in advance!
Preprocessing runs before compilation. It handles the source code as plain text, it doesn't care for C++ language semantics.
The reason why var is not defined is that a preprocessor definition is valid from the point of definition until the end of the file (preprocessed translation unit) or a corresponding #undef.
Several weeks ago, SBCL updated 2.0.2 and brought the Block compilation feature. I have read this article to understand what it is.
I have a question, what's the difference between (declaim (inline 'some-function)) and Block compilation? Block compilation is automatic by the compiler?
Thanks.
Inline compilation is a specific optimization technique. A function being called is directly integrated into the calling function - usually using its source code - and then compiled.
This means that the inlined function might not be inlined only in one function, but in multiple functions.
Advantage: the overhead of calling a function disappears.
Disadvantage: the code size increases and the calling function(s) needs to be recompiled, when the inlined function changed and we want this change to become visible. Macros have the same problem.
Block compilation means that a bunch of code gets compiled together with different semantic constraints and that this enables the compiler to do a bunch of new optimizations.
Common Lisp has in the standard support for block compilation of single files. It allows the file compiler to assume that a file is such a block of code.
Example from the Common Lisp standard:
3.2.2.3 Semantic Constraints
A call within a file to a named function that is defined in the same file refers to that function, unless that function has been declared notinline. The consequences are unspecified if functions are redefined individually at run time or multiply defined in the same file.
This allows the code to call a global function and not use the symbol's function cell for the call. Thus this disables late binding for global function calls - in this file and for functions in this file.
It's not said how this can be achieved, but the compiler might just allocate the code somewhere and the calls just jump there.
So this part of block compilation is defined in the standard and some compilers are doing that.
Block compilation for multiple files
If the file compiler can use block compilation for one file, then what about multiple files? A few compilers can also tell the file compiler that several files make a block for compilation. CMUCL does that. SBCL was derived and simplified from CMUCL and lacks it until now. I think Lucid Common Lisp (which is no longer actively sold) did support something like that, too.
Might be useful to add this to SBCL, too.
How does make-array work in SBCL? Are there some equivalents of new and delete operators in C++, or is it something else, perhaps assembler level?
I peeked into the source, but didn't understand anything.
When using SBCL compiled from source and an environment like Emacs/Slime, it is possible to navigate the code quite easily using M-. (meta-point). Basically, the make-array symbol is bound to multiple things: deftransform definitions, and a defun. The deftransform are used mostly for optimization, so better just follow the function, first.
The make-array function delegates to an internal make-array% one, which is quite complex: it checks the parameters, and dispatches to different specialized implementation of arrays, based on those parameters: a bit-vector is implemented differently than a string, for example.
If you follow the case for simple-array, you find a function which calls allocate-vector-with-widetag, which in turn calls allocate-vector.
Now, allocate-vector is bound to several objects, multiple defoptimizers forms, a function and a define-vop form.
The function is only:
(defun allocate-vector (type length words)
(allocate-vector type length words))
Even if it looks like a recursive call, it isn't.
The define-vop form is a way to define how to compile a call to allocate-vector. In the function, and anywhere where there is a call to allocate-vector, the compiler knows how to write the assembly that implements the built-in operation. But the function itself is defined so that there is an entry point with the same name, and a function object that wraps over that code.
define-vop relies on a Domain Specific Language in SBCL that abstracts over assembly. If you follow the definition, you can find different vops (virtual operations) for allocate-vector, like allocate-vector-on-heap and allocate-vector-on-stack.
Allocation on heap translates into a call to calc-size-in-bytes, a call to allocation and put-header, which most likely allocates memory and tag it (I followed the definition to src/compiler/x86-64/alloc.lisp).
How memory is allocated (and garbage collected) is another problem.
allocation emits assembly code using %alloc-tramp, which in turns executes the following:
(invoke-asm-routine 'call (if to-r11 'alloc-tramp-r11 'alloc-tramp) node)
There are apparently assembly routines called alloc-tramp-r11 and alloc-tramp, which are predefined assembly instructions. A comment says:
;;; Most allocation is done by inline code with sometimes help
;;; from the C alloc() function by way of the alloc-tramp
;;; assembly routine.
There is a base of C code for the runtime, see for example /src/runtime/alloc.c.
The -tramp suffix stands for trampoline.
Have also a look at src/runtime/x86-assem.S.
I have heard that MATLAB has an automatic in-need compilation of functions which could create a lot of function-call overhead if you call a function many times like in the following code:
function output = BigFunction( args )
for i = 1:10000000
SmallFunction( args );
end
end
Is it faster to call the function SmallFunction() if I put it in the same file as BigFunction() as a local function? Or is there any good solution other than pasting the code from SmallFunction() into the BigFunction() to optimize the performance?
Edit: It may be false assumption that the function-call overhead is because of the in-need compilation. The question is how to cut down on the overhead without making the code look awful.
Matlab hashes the functions it reads into memory. The functions are only compiled once if they exist as an independent function in its own file. If you put BigFunction in BigFunction.m and SmallFunction in SmallFunction.m then you should recieve the optimization benefit of having the m-script compiled once.
The answer to my first question is that a local function performs the same as a function in another file.
An idea for the second question is to, if possible, make SmallFunction() an inline-function, which has less function-call overhead. I found more about function-call performances in the MathWorks forum, and I paste the question and answer below:
Question:
I have 7 different types of function call:
An Inline function. The body of the function is directory written down (inline).
A function is defined in a separate MATLAB file. The arguments are passed by the calling function (file-pass).
A function is defined in a separate MATLAB file. The arguments are provided by referencing global variables; only indices are provided by the calling function (file-global).
A nested function. The arguments are passed by the enclosing function (nest-pass).
A nested function. The arguments are those shared with the enclosing function; only indices are provided by the enclosing function (nest-share).
A sub function. The arguments are passed by the calling function (sub-pass).
A sub function. The arguments are provided by referencing global variables; only indices are provided by the calling function (sub-global).
I would like to know which function call provides better performance than the others in general.
The answer from MathWorks Support Team pasted here:
The ordering of performance of each function call from the fastest to the slowest tends to be as follows:
inline > file-pass = nest-pass = sub-pass > nest-share > sub-global > file-global
(A>B means A is faster than B and A=B means A is as fast as B)
First, inline is the fastest as it does not incur overhead associated with function call.
Second, when the arguments are passed to the callee function, the calling function sets up the arguments in such a way that the callee function knows where to retrieve them. This setup associated with function call in general incurs performance overhead, and therefore file-pass, nest-pass, and sub-pass are slower than inline.
Third, if the workspace is shared with nested functions and the arguments to a nested function are those shared within the workspace, rather than pass-by-value, then performance of that function call is inhibited. If MATLAB sees a shared variable within the shared workspace, it searches the workspace for the variable. On the other hand, if the arguments are passed by the calling function, then MATLAB does not have to search for them. The time taken for this search explains that type nest-share is slower than file-pass, nest-pass, and sub-pass.
Finally, when a function call involves global variables, performance is even more inhibited. This is because to look for global variables, MATLAB has to expand its search space to the outside of the current workspace. Furthermore, the reason a function call involving global variables appears a lot slower than the others is that MATLAB Accelerator does not optimize such a function call. When MATLAB Accelerator is turned off with the following command,
feature accel off
the difference in performance between inline and file-global becomes less significant.
Please note that the behaviors depend largely on various factors such as operating systems, CPU architectures, MATLAB Interpreter, and what the MATLAB code is doing.
I am using MSVC 6.0 to call a macro in the Win32API and I'm getting an access violation. I know that the pointers I'm passing to the macro contain valid addresses, though they're evidently not pointing to the correct data.
The macro accepts multiple pointers, and I'm not sure which pointer is erroneous, so I'd like to use MSVC's debugger to 'step into' the macro to see exactly where the problem is. When I've tried thus far, the debugger just throws the access violation error.
Is it possible to 'step into' a macro using MSVC 6.0's debugger? If not, is there anyway for me to check what the macro expands to, so I can get a better idea of what I'm not doing correctly?
If you really need to trace the macro code, the only way would be to find the definition of the macro, manually "instantiate" the macro code (substituting the parameters) in place where it is "called", and then trace it in the debugger as ordinary code.
Alternative variant would be to step through the disassembly, if your skill level is sufficient to back-associate the disassembled code with the original macro code.
You cannot step into the macro because at the point compiler does its job, the macro is already expanded. However, you can step through a macro - if you just do "step", you will actually step through all code inside the macro as if it was expanded, line by line. If you to "step into", you will step into every function call made from that macro. If the macro is small enough, and/or you know it very well, you can do a "blind step through" that way.
You can step into functions that are called from the macro but as far as I know can not really step through the macro lines themselves. And yes if you code compiles - you can find the macro definition (use MSVC function/class browser to find where it is defined, some header file probably)
I'd just step into the disassembly - usually, even if you're not an assembly expert, short runs of code (a few lines) the assembly map back to the C/C++ code pretty readily (especially in non-Release builds). Hopefully the macro isn't so hairy that that isn't the case here.
Remember that plenty of debugging occurs even without source code, so having the source and the disassembly together usually isn't too bad. And if it's something you haven't much experience with, it's great experience to get.