Page 2 of 2 FirstFirst 12
Results 11 to 19 of 19

Thread: C Language Modules For LLVM Still Being Tackled

  1. #11
    Join Date
    Sep 2008
    Posts
    121

    Default

    Quote Originally Posted by porkbutt View Post
    Who would re-write their C code for LLVM so that they can lose 50% of their performance but gain some useless "compiler modularity"?
    They aren't even suggesting you would rewrite any code. And you wouldn't lose any performance nor would you gain any either. And the noone has mentioned anything related to "compiler modularity".

    The most direct effect of this would be that faster compilation and smaller and more logically constructed ASTs for clang. Presumable faster linking as well.
    Long term it could make C/C++ much move convenient to use, and less patching shit together with preprocessor macros which is what we do now. No performance loss anywhere.
    Those are very very good reasons why you should "screw with it".

  2. #12
    Join Date
    Oct 2011
    Location
    Germany
    Posts
    238

    Default

    As I see the replace the prerpocessor with an module system, but why don't improve the preprocessor and use the filesystem for the submodule stuff?

  3. #13
    Join Date
    Sep 2008
    Posts
    121

    Default

    Quote Originally Posted by Thaodan View Post
    As I see the replace the prerpocessor with an module system, but why don't improve the preprocessor and use the filesystem for the submodule stuff?
    I'm not sure in what way you want to improve the preprocessor. It does exactly what it should be doing. It just that copy pasting code like #include is fragile and inefficient, and there is no way to the compiler to know that something #included. Some code relies on this behavior (things like OpenFOAM even abuses #include all the time). The compiler needs to know that you are trying to import a module, so you cant do it solely with a preprocessor.

    They are going to give special treatment to
    #include <*>
    macros and map them to the corresponding import statement (which will be the correct thing to do in all well behaved C/C++ code). If you have some obscure code, then you just turn off that feature and compile the old way.
    So, in the backwards compatible mode, you won't change anything in your code, and compilation will just be faster. If it becomes standard, you can make use of all the other advantages they mention.

  4. #14
    Join Date
    Feb 2013
    Posts
    6

    Default

    Quote Originally Posted by Micket View Post
    They aren't even suggesting you would rewrite any code. And you wouldn't lose any performance nor would you gain any either. And the noone has mentioned anything related to "compiler modularity".

    The most direct effect of this would be that faster compilation and smaller and more logically constructed ASTs for clang. Presumable faster linking as well.
    Long term it could make C/C++ much move convenient to use, and less patching shit together with preprocessor macros which is what we do now. No performance loss anywhere.
    Those are very very good reasons why you should "screw with it".
    Oh, I see... So like how GCC and the Linux kernel are both bad for having/using GNU extensions that everyone whines about making it difficult for LLVM to compile the Linux kernel, LLVM too wants to add their own set of extensions to create the exact opposite situation...

    LLVM is the Wayland of compilers.... It'll be really good in 5 more years, you just wait :P

    Somebody please PM me when LLVM has anything to offer over GCC for a C developer like myself, because I'm writing it off as useless and a waste of my time for now.

    Things I would care about:
    * performance of the compiled binary

    Things GCC currently beats LLVM up in and takes it's lunch money:
    * performance of the compiled binary

  5. #15
    Join Date
    May 2012
    Location
    Colombia
    Posts
    19

    Default

    Quote Originally Posted by michal View Post
    Might be cool idea. This should be proposed as standard and discussed by Stroustrup and rest of the standard team. Because it doesn't makes any sense to implement such things outside the standards.
    What has Stroustrup to do with C?

  6. #16
    Join Date
    Jun 2011
    Posts
    824

    Default

    Quote Originally Posted by porkbutt View Post
    Oh, I see... So like how GCC and the Linux kernel are both bad for having/using GNU extensions that everyone whines about making it difficult for LLVM to compile the Linux kernel, LLVM too wants to add their own set of extensions to create the exact opposite situation...
    All compilers have their own extensions, however as a programmer you really should be writing standards compliant code rather than relying upon compiler behavior. However unless you're using imports directly I wouldn't really consider this an extension so much as a compiler implementation detail that is speeding up compilation.

    Quote Originally Posted by porkbutt View Post
    LLVM is the Wayland of compilers.... It'll be really good in 5 more years, you just wait :P
    both are at 90% of what they need to be good, and they are far better designs over the monolithic applications they're replacing. We're talking a year or two for GNOME and KDE for wayland and LLVM basically needs OpenMP and a bit further optimization work before it totally beats out GCC. There is really no question for if on either, but only a matter of when. The more modular and thus better designed will always in the end run beat out the monolithic. even when the monolithic design has a massive head start. Eventually even linux say 20-30 years down the line will be losing out to some sort of microkernel, it's just how the FOSS software industry works.

    Quote Originally Posted by porkbutt View Post
    Somebody please PM me when LLVM has anything to offer over GCC for a C developer like myself, because I'm writing it off as useless and a waste of my time for now.

    Things I would care about:
    * performance of the compiled binary

    Things GCC currently beats LLVM up in and takes it's lunch money:
    * performance of the compiled binary
    That's only true if you use OpenMP otherwise LLVM vs GCC binary performance wise is a tossup right now, as of the latest results on phoronix. Also kinda hard to believe you're a developer if the only thing you care about is the performance of the binary. As a developer myself things like debugging tools, compilation speed, and IDE integration as well as LLVM being a testing ground for cool ideas such as JITed C++ code and this import thing and that it provides a basis that any other language can be built on top of including the JVM and .NET languages make it interesting for me and a useful tool for development.

  7. #17
    Join Date
    Jun 2011
    Posts
    824

    Default

    Quote Originally Posted by Desiderantes View Post
    What has Stroustrup to do with C?
    CLang covers more than C, it covers C++ and Objective-C(++) as well, and being accepted by the C++ standards committee would probably also result in it being accepted by the C standard committee as well.

  8. #18
    Join Date
    Apr 2011
    Posts
    302

    Default

    Quote Originally Posted by porkbutt View Post
    How dare they attempt to fork the tried and true standard and do their own thing!!!!!!!!!!

    Oh, LLVM has nothing to do with Canonical?

    I mean, what a great initiative, good for them!!!!


    On a slightly more serious note, C is a low level language, and there's no reason to ever screw with it, C89 and C99 should continue being the standard dialects for all of eternity. C has a niche in low level, high performance STANDARDIZED UNIX-like code, this is another fine example of the stupidity of LLVM. Who would re-write their C code for LLVM so that they can lose 50% of their performance but gain some useless "compiler modularity"?

    C++ has always sucked, confusing syntax, confusing memory management, and is pretty much a memory leak waiting to happen. I guess it's better than the proven failures that managed languages like C# and Java are, but falls short of the interpreted languages like Python and Perl for ease of use. It's funny to hear supposed Linux fanboys speak of C# as if it was some holy grail, what great ground breaking applications were written in C#? Answer: there are none. Even big name Java applications like Netbeans and Eclipse are so slow and buggy, they'd be better off written in PyQt than Java.


    Sorry but you are wrong and you not thinking. LLVM can compile 85-90% of the available code. You need small changes in your program for sure. But it's proven that a program written with C11 and compiled with LLVM, its as fast as if it was compiled with GCC or any other compiler. Changing code to be compatible with LLVM doesn't show any speed regressions. Same goes for Java-LLVM and OpenCL-LLVM. This type of portable compile suit (LLVM like) should there from the beginning of the compilers, many decades before. Statically builded programs there shouldn't exist in the first place. And finally no instruction sets wars consoles and emulators. Intel-MS started the evil with static-compilers and everyone stupid of as, followed.

  9. #19
    Join Date
    Sep 2008
    Posts
    121

    Default

    Quote Originally Posted by porkbutt View Post
    Oh, I see... So like how GCC and the Linux kernel are both bad for having/using GNU extensions that everyone whines about making it difficult for LLVM to compile the Linux kernel, LLVM too wants to add their own set of extensions to create the exact opposite situation...
    Except that the message you replied to said the exact fucking opposite. Your code won't fucking need to change. It will still compile fine with any other compiler.
    This is in no way an extension.

    LLVM is the Wayland of compilers.... It'll be really good in 5 more years, you just wait :P

    Somebody please PM me when LLVM has anything to offer over GCC for a C developer like myself, because I'm writing it off as useless and a waste of my time for now.

    Things I would care about:
    * performance of the compiled binary

    Things GCC currently beats LLVM up in and takes it's lunch money:
    * performance of the compiled binary
    Here are the things I, and many many others, care about, since I compile my software maybe a hundred times every day;
    * speed of compilation

    Things that this include->import would improve
    * speed of compilation

    Negative side effects
    * None

    And when I've finished developing the software (99.9% of the time spent there) I'll just use Intels compiler or GCC to run my software. Well. Actually I might just use clang again because the difference is usually insignificant.


    Clang developers introduce a much needed (optional) feature which would significantly cut down compilation times in a completely backwards compatible way... and some people still complain?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •