Date: Sun, 24 Jun 2012 20:50:27 +0000 (UTC) From: jb <jb.1234abcd@gmail.com> To: freebsd-questions@freebsd.org Subject: Re: CLANG vs GCC tests of fortran/f2c program Message-ID: <loom.20120624T221657-6@post.gmane.org> References: <26.30.12873.06EE2EF4@smtp02.insight.synacor.com> <20120621230302.GB575@hemlock.hydra>
next in thread | previous in thread | raw e-mail | index | archive | help
Chad Perrin <perrin <at> apotheon.com> writes: > > Anyway, switching from GCC to Clang has essentially nothing to do with > the kinds of problems we increasingly see in the Linux world. In fact, > one of the biggest problems in the Linux world is the fact that GNU > projects have a tendency to degrade in quality over time and pretty > thoroughly undermine the Unix philosophy in egregious ways, which means > that the sooner we can divest ourselves of GNU tools (including GCC) the > better off we will probably be (though I would still advocate a measured > approach to replacing GNU tools, rather than a headlong rush without any > forethought). > Some Linux distros are starting to integrate clang into their environment. GPL had been introduced to address certain philosophical problems felt by devs, namely how to make sure that their products do not get hijacked by people who do not want to contribute back (because they are unscrupulous, or do not share with devs the same values). Fair enough. GPL has not been challenged in court of law perhaps for a good reason yet. One could be that its enemies are content with what it represents in their view and so why should they bother trying to protect its followers from hurting themselves ? They believe that GPL is viral, but not fascist yet and anybody of different philosophy can just ignore it and go their own licensing way. Another could be that its enemies want it to reach a critical mass of participation, so when they hit, it will be big time and hopefully deadly. Things like that need time, and perhaps some errors by GPL advocates. It is also possible (why not ?) that GPL will self-destruct - there are indications that they are going down, down, down as a choice of license. I believe GPL can be confusing in its interpretation - even its followers are confused, and that's the seeds of destructions as I see it (btw, I have participated in some discussion of GPL that made me and other participant feel its current interpretation is vulnerable, and so with potential significant effect on a business model dependent on it.). GPLv3 apparently introduced a very sensitive question: Does GPLv3 apply to gcc only, or it *may* apply to code generated by gcc as well ? and until it gets answered any responsible dev or business should stay away from it. If so, then it follows that the dev or the bussiness do not want to live in a "LaLaLand according to GPL"; they want to conduct activities based on sound rules - who in her right mind would blame them for that ? So, you cut the GPL cord now and go your own way, the sooner the better. This is the most important factor, in any business - clarity of contract, license law. I would strongly disagree with Wojciech's assertion that only performance of compiler generated code really counts. >From the software purchaser's point of view, yes, she wants the app that was paid for fast, let's be realistic. But if you consider devs or software houses, that will be more subtle. I think the design and maintainability of compiler source code decides about quality of that tool in a significant way, equally or perhaps even little more than its speed or that of generated code alone - after all it is a tool on which software product depends now and in the future. And this translates into e.g. maintenance costs, a matter of interest to purchaser of software and others, in general the so called users. I am more concerned about an aspect of the language the clang tools are written in, namely the use of object-oriented paradigm of c++ (it is a phony paradigm, one that does not exist in nature or reality, which explains the failure rate of C++ OO projects historically and current usage decline). I sense that the relative slowness of generated code has to do with it. Perhaps some other attributes of that code's quality too, even if not now, then in the future. As one can see even by the test results done in 2010: http://www.phoronix.com/scan.php?page=article&item=gcc_llvm_clang&num=1 clang looked good vice gcc. There was an improvement since then, e.g.: http://www.phoronix.com/scan.php?page=news_item&px=MTA5Nzc Once again, in a matter like choice of tools you make your living with, you should not gamble - the more clarity you have the better. Once you decide what your philosophy, license model, and business requiremnts are, you just go and do not look back. The choice was made (perhaps GPL helped make that choice ...) - it is clang compiler tools. jb
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?loom.20120624T221657-6>