Hello, i want to start running some microbenchmarks on Apples Swift-language.
However i feel it is hard to find proper documentation for the different options in regards of compiler optimization.
I have read a lot of questions and articles about other peoples microbenchmarks of the language, however it would be nice to have some firm documentation on the subject.
In the latest beta, the ones to use seems to be:
-Onone
No optimizations
-O
Safe optimizations?
-Ounchecked (Replaced -Ofast)
Unsafe optimizations, (No checks for integer overflow, array out of bounds etc)
My question is, are these all my possible options? And does anybody have some resource that documents this?
EDIT:
I have found similar documention to the one i need about objective-c with gcc here:
https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html section 2.8. This is what i need for Swift..
Related
Let's say that someone wants to extend the OpenMP functionality, by adding, for example a new directive newdir with some clauses e.g newclause in order to use a code in the form
#pragma omp newdir (newclause)
or something like that. I know that OpenMP is a language extension and therefore this requires the modification of the gcc source code to support the new syntax (and of course the corresponding changes in the libgomp runtime). I am looking for documentation on how this can be done, if not detailed, at least some hints as a starting point for further research on this subject. Thanks.
I did not try anything yet, this is just a question
The ComplexExpr and ComplexFunc classes in the links below seem very convenient to work with complex numbers. Is there a plan to include them into the official Halide API? Or is there a reason why they are not included?
https://github.com/halide/Halide/blob/master/apps/fft/complex.h
https://github.com/halide/Halide/blob/be1269b15f4ba8b83df5fa0ef1ae507017fe1a69/apps/fft/funct.h
Speaking as a Halide developer...
Or is there a reason why they are not included?
We haven't included these historically since we didn't want to bless a particular representation for complex numbers. There are a few valid ways of dealing with them and the headers in question are just one.
Is there a plan to include them into the official Halide API?
We've started talking about packaging some of this type of code into a set of header-only "Halide tools" libraries, so named to avoid the normative implication of calling it something like "stdlib". So as of right now, there is no concrete plan, but the odds are nonzero.
In the meantime, the code is MIT licensed, so you should feel free to use those files, regardless.
I'm using GCC 4.7.2. My code is rather heavy on template, STL and boost usage. When I compile and there is an error in some class or function that is derived from or uses some boost/STL functionality, I get error messages showing spectacularly hideous return types and/or function arguments for my classes/function.
My question:
Is there a prettyprint type of thing for GCC warnings/errors containing boost/STL types, so that the return types shown in error messages correspond to what I've typed in the code, or at least, become more intelligible?
I have briefly skimmed through this question, however, that is about GDB rather than GCC...
I've also come across this pretty printer in Haskell, but that just seems to add structure, not take away (mostly) unneeded detail...
Any other suggestions?
I asked a similar question, where someone suggested I try gccfilter. It's a Perl script that re-formats the output of g++ and colorizes it, shortens it, hides full pathnames, and lots more.
Actually, that suggestion answers this question really well too: it's capable of hiding unneeded detail and pretty-printing both STL and boost types. So: I'll leave this here as an answer too.
The only drawback I could see is that g++ needs to be called from within the script (i.e., piping to it is not possible at the time). I suspect that's easily fixed, and in any case, it's a relatively minor issue.
You could try STLfilt as mentioned in 'C++ Template Metaprogramming' by David Abrahms & Alesky Gurtovoy.
The book contains a chapter on template message diagnostics. It suggests using the STLFilt /showback:N to eliminate compiler backtrace material in order to get simplified output.
(Mathematica version: 8.0.4)
lst = Names["Internal`*"];
Length[lst]
Pick[lst, StringMatchQ[lst, "*Bag*"]]
gives
293
{"Internal`Bag", "Internal`BagLength", "Internal`BagPart", "Internal`StuffBag"}
The Mathematica guidebook for programming By Michael Trott, page 494 says on the Internal context
"But similar to Experimental` context, no guarantee exists that the behavior and syntax of the functions will still be available in later versions of Mathematica"
Also, here is a mention of Bag functions:
Implementing a Quadtree in Mathematica
But since I've seen number of Mathematica experts here suggest Internal`Bag functions and use them themselves, I am assuming it would be sort of safe to use them in actual code? and if so, I have the following question:
Where can I find a more official description of these functions (the API, etc..) like one finds in documenation center? There is nothing now about them now
??Internal`Bag
Internal`Bag
Attributes[Internal`Bag]={Protected}
If I am to start using them, I find it hard to learn about new functions by just looking at some examples and trial and error to see what they do. I wonder if someone here might have a more complete and self contained document on the use of these, describe the API and such more than what is out there already or a link to such place.
The Internal context is exactly what its name says: Meant for internal use by Wolfram developers.
This means, among other things, the following things hold about anything you might find in there:
You most likely won't be able to find any official documentation on it, as it's not meant to be used by the public.
It's not necessarily as robust about invalid arguments. (Crashing the kernel can easily happen on some of them.)
The API may change without notice.
The function may disappear completely without notice.
Now, in practice some of them may be reasonably stable, but I would strongly advise you to steer away from them. Using undocumented APIs can easily leave you in for a lot of pain and a nasty surprise in the future.
What are coding conventions and guidelines you suggest for writing Bison (.y) and flex (.lex) files?
Please address the length of the code sections and their style.
Thanks,
Asaf
P.S.,
There's an old thread about it here, but I'm looking for a more detailed answer (and to have it on SO!).
For questions like this in general I would typically see what other people have done. Good resources for this are Google Code Search and Koders. Both support searching by a specific programming language; however it appears that only Google has lex as a listed language.
Other than that, I generally try to keep to either 79 or 96 columns in source code, to make sure I can view at least 2 windows-worth of code side by side.