Anybody using Intel's compilers on Slackware 14.0 x86_64?

[Slacky]

Before I sign up for it I would like to know if there are any installation
issues using Intel's 2013 non-commercial compilers on Slack 14.

TIA,
Paul

[Henrik Carlqvist]

I haven't tried their non-commercial compilers and I have not tried
Slackware 14, but I have installed and some of my users have used their
commercial icc on 64 bit Slackware 13.1.

On Slackware I was able to install the compiler, but not their profiling
tool. This was a few years ago, and I don't remember exactly how I did to
install icc and why I failed to install the profiler, but if I remember
right their installation script assumed that you had one of their
supported Linux distributions. To install icc I probably converted a
number of rpm files to tgz files which I installed.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc351(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

[Slacky]

On 2013-05-15, Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:
> On Slackware I was able to install the compiler, but not their profiling
> tool. This was a few years ago, and I don't remember exactly how I did to
> install icc and why I failed to install the profiler, but if I remember
> right their installation script assumed that you had one of their
> supported Linux distributions. To install icc I probably converted a
> number of rpm files to tgz files which I installed.

I did a trial install in a Slackware 14.0 VM and it was not very smooth.
You're right it does appear they expect only certain distros to be used to
host their product. The installer couldn't find gtk 2 (wanted 2.4 or above)
even though Slackware 14 has a gtk 2.20-something. And there was another
glitch or two. The command line compiler installs fine but you don't get the
debugger GUI. I guess there is something to paying for Red Hat etc. after
all but not for a home user. The other recommended distros are so old you
have a difficult time finding downloads. I'll be damned if I use U-Punt-U.
Debian and its ripoffs are the most frustrating distros ever for a Slackware
user. apt is crapt. Thank Pat for Slackware!

Cheers,

>
> regards Henrik

[jo...@wexfordpress.com]

What would be the advantage in using the Intel product as compared to
Gcc etc.?

John Culleton

[Henrik Carlqvist]

On Thu, 16 May 2013 12:11:21 +0000, Slacky wrote:
> The command line compiler installs fine but you don't get the debugger
> GUI. I guess there is something to paying for Red Hat etc. after all
> but not for a home user.

I haven't tried it myself, but the free distribution CentOS might be
worth trying if you really need a complete intel compiler environment.
From http://www.centos.org/ :
-8<--------------------------------
CentOS is an Enterprise-class Linux Distribution derived from sources
freely provided to the public by a prominent North American Enterprise
Linux vendor. CentOS conforms fully with the upstream vendor's
redistribution policy and aims to be 100% binary compatible. (CentOS
mainly changes packages to remove upstream vendor branding and artwork.)
CentOS is free.
-8<--------------------------------
They do not mention RedHat, but that is the upstream vendor they are
following.

On the other hand, there are other good tools for both debugging and
profiling which works fine with Slackware. I prefer ddd for debugging
myself and valgrind for profiling. Running valgrind might be slow, but if
I remember right the intel profiler required some proprietary kernel
module which would taint the kernel.

[Henrik Carlqvist]

On Thu, 16 May 2013 06:23:12 -0700, jo...@wexfordpress.com wrote:
> What would be the advantage in using the Intel product as compared to
> Gcc etc.?

The generated binaries might be faster. Some years ago when I installed
their compiler it did also support some SSE instructions that gcc did not
yet support.

[Slacky]

On 2013-05-16, jo...@wexfordpress.com <jo...@wexfordpress.com> wrote:

That question is a bit hard to understand. About the only thing positive you
can say about gcc is it's free as in beer and "works" on a lot of platforms.
All of gcc is bloated, buggy, and doesn't optimize well usually. If it's all
you know then you might like it. Personally I think the options are out of
control with gcc. Every bug and workaround is implemented as an option
instead of actually fixing gcc. By the time you get your makefile built you
have a whole page of switches to get anything to compile like it should,
with the right combinations of stuff to get the proper warnings. True blue
chickenshit and worth price paid.

Compilers from chip vendors are always better than gcc, but they only run
on their own platforms obviously. Intel's compilers spank most or all of the
competition pretty badly on Intel chips. And since they actually pay people
to support them they usually have most of the latest language support. They
have a fairly nice debugger GUI from what I've seen, certainly it beats the
bloddy hell out of ddd, insight, gvd, etc. The only thing is like Henrick
points out they tend to target commercial distros like Red Hat and
Suse. Henrick thanks for reminding me about CentOS. It's frustrating to use
Red Hat for a Slackware guy but a lot better than Debian!

Once you Slack you never go back.

[Henrik Carlqvist]

On Sun, 19 May 2013 15:25:19 +0000, Slacky wrote:
> About the only thing positive you can say about gcc

I wouldn't be that hard on gcc as I find it a rather impressive compiler.
I have compared gcc not only against icc but also some other compilers
like Open64 and tcc.

> is it's free as in beer

Gcc is not only free as in beer but also as in speech as it has the GPL
license.

> and "works" on a lot of platforms.

The value of how well it "works" should not be underestimated. Once when
I compared gcc with some other compilers which were supposed to generate
very optimized code I found that they might have been able to do the
calculations faster on the code that I used as a benchmark, but
unfortunately they calculated the wrong result.

> All of gcc is bloated, buggy, and doesn't optimize well
> usually.

Usually icc optimizes a little better, but with the switch -O2 gcc
generates rather well optimized binaries. I also find the compilation
times rather fast with gcc. Do you have any benchmarks which points to
better results from other compilers?

> Personally I think the options are out of control with gcc.

Usually I compile with "gcc -c -O2 file.c". Sometimes, if I wan't to be
more strict and want to have some extra warnings I might add some more
language specific flags like:

"gcc -ansi -pedantic -Wall -O2 file.c" or
"gcc -std=gnu99 -O2 file.c" if someone has added C99 code to the sources.

> Every bug and workaround is implemented as an option instead of
> actually fixing gcc.

Do you have any examples of such switches?

> By the time you get your makefile built you have a whole page of
> switches to get anything to compile like it should, with the right
> combinations of stuff to get the proper warnings.

If you want warnings for not following a specific standard the problem
might be that there are so many different standards.

[Slacky]

On 2013-05-19, Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:
> On Sun, 19 May 2013 15:25:19 +0000, Slacky wrote:
>> About the only thing positive you can say about gcc
>
> I wouldn't be that hard on gcc as I find it a rather impressive compiler.
> I have compared gcc not only against icc but also some other compilers
> like Open64 and tcc.
>
>> is it's free as in beer
>
> Gcc is not only free as in beer but also as in speech as it has the GPL
> license.

Free as in speech? As in if I say something you said I have to allow you to
publish everything I say? I don't get the (broken) comparison. GPL is not
free, it's a viral forcible open source license.

>
>> and "works" on a lot of platforms.
>
>
> The value of how well it "works" should not be underestimated.

It first has to be quantified because in truth 99.99% of people don't know
anything beside Intel exists and have no basis for comparison. If you have
other hardware you'll quickly appreciate other toolchains than gcc.

>> All of gcc is bloated, buggy, and doesn't optimize well
>> usually.
>
> Usually icc optimizes a little better, but with the switch -O2 gcc
> generates rather well optimized binaries. I also find the compilation
> times rather fast with gcc. Do you have any benchmarks which points to
> better results from other compilers?

Personally, no. But I can point out two respected sources that do:

Agner Fog has pointed out repeatedly Intel's compilers kick unholy ass on
Intel hardware. You can find this on his forums. This is what I have been
telling you. Is it surprising Intel knows how to write good code for their
chips? You can bet Oracle knows (knew?) how to write code for SPARC better
than the best gcc people and MIPS knows how to write better MIPS code than
the best gcc people. Sometimes there's a bit of crossover but usually not
much.

Benchmarks are available on Polyhedron.com. gcc 4.7.2 takes a serious
beating from Intel last time anyone looked. That is not necessarily a
dismissal of gnu. For what you pay gnu is the better deal. But it is silly
to assert gnu is better than stuff written by the people who make the target
chips. That's just not sensible.

>
>> Personally I think the options are out of control with gcc.
>
> Usually I compile with "gcc -c -O2 file.c". Sometimes, if I wan't to be
> more strict and want to have some extra warnings I might add some more
> language specific flags like:
>
> "gcc -ansi -pedantic -Wall -O2 file.c" or
> "gcc -std=gnu99 -O2 file.c" if someone has added C99 code to the sources.
>
>> Every bug and workaround is implemented as an option instead of
>> actually fixing gcc.
>
> Do you have any examples of such switches?

I would say a good 75% of the switches are good examples. I've seen two
compiler writers say the same thing. I'm sure more think it ;-)

>
>> By the time you get your makefile built you have a whole page of
>> switches to get anything to compile like it should, with the right
>> combinations of stuff to get the proper warnings.
>
> If you want warnings for not following a specific standard the problem
> might be that there are so many different standards.

The fact the gnu narcicists made up their own standard doesn't help here.

>
> regards Henrik

The Intel toolchain is now working supremely on my Slack 14 x86_64
setup. Thank you Pat and Intel!

Cheers,

Slacky

[Aragorn]

On Monday 10 June 2013 11:38, Slacky conveyed the following to
alt.os.linux.slackware...

> On 2013-05-19, Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:
>
>> I wouldn't be that hard on gcc as I find it a rather impressive
>> compiler. I have compared gcc not only against icc but also some
>> other compilers like Open64 and tcc.
>>
>>> is it's free as in beer
>>
>> Gcc is not only free as in beer but also as in speech as it has the
>> GPL license.
>
> Free as in speech? As in if I say something you said I have to allow
> you to publish everything I say? I don't get the (broken) comparison.
> GPL is not free, it's a viral forcible open source license.

The comparison of the word "free" in Free Software with "free speech" is
just a semantic one, because more correctly would be to say "free as in
freedom".

The GPL may be a nuisance to many developers, but at least it guarantees
that the freedom you received when you decided to use, study, modify or
distribute the code cannot be abused to deny someone else the same
rights.

By the way, even the comparison of the GPL with free speech doesn't mean
that if you use GPL'd code, everything you do will be published. You
are allowed to use GPL'd code and modify it without publishing your
source code, so long as you also don't publish the binary code then.

It is only when you decide to _distribute_ code - in any form or guise -
which is _a derivative of_ the GPL'd code, that you are obligated to
also supply the source code _to_ that derivative code, as well as that
you must allow others to obtain the original GPL'd code of which your
code is a derivative. Commonly, the modified/derivative code is then
published as a patch and a (working) link to the original code is
supplied.

> Agner Fog has pointed out repeatedly Intel's compilers kick unholy ass
> on Intel hardware.

But not on AMD hardware.

> You can bet Oracle knows (knew?) how to write code for SPARC better

> than the best gcc people [...]

Uhh, that would have been Sun Microsystems, not Oracle. Oracle bought
Sun Microsystems not too long ago, but they certainly didn't create the
SPARC architecture, nor any compilers for it.

[Michael Black]

On Tue, 11 Jun 2013, Aragorn wrote:

> On Monday 10 June 2013 11:38, Slacky conveyed the following to
> alt.os.linux.slackware...
>
>> On 2013-05-19, Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:
>>
>>> I wouldn't be that hard on gcc as I find it a rather impressive
>>> compiler. I have compared gcc not only against icc but also some
>>> other compilers like Open64 and tcc.
>>>
>>>> is it's free as in beer
>>>
>>> Gcc is not only free as in beer but also as in speech as it has the
>>> GPL license.
>>
>> Free as in speech? As in if I say something you said I have to allow
>> you to publish everything I say? I don't get the (broken) comparison.
>> GPL is not free, it's a viral forcible open source license.
>
> The comparison of the word "free" in Free Software with "free speech" is
> just a semantic one, because more correctly would be to say "free as in
> freedom".
>
> The GPL may be a nuisance to many developers, but at least it guarantees
> that the freedom you received when you decided to use, study, modify or
> distribute the code cannot be abused to deny someone else the same
> rights.
>
> By the way, even the comparison of the GPL with free speech doesn't mean
> that if you use GPL'd code, everything you do will be published. You
> are allowed to use GPL'd code and modify it without publishing your
> source code, so long as you also don't publish the binary code then.
>

A counter example is the time I had an assembler for the Radio Shack
Color COmputer, and I wanted to put program listings in a binder. I
couldn't, there was no way to print a left margin. So I disassembled the
code, not all of it but enough to find where the printing took place, and
added a patch to print about five spaces after each carriage return.

If the source code was there, I wouldn't have had to take apart the
program. That made the effort so much more trouble. But conversly, the
license said I wasn't allowed to disassemble the program. Which meant
that the work I did wasn't really something I could spread around. So the
effort in finding where to put the patch was "costly" since I made the
effort but couldn't share it and anyone else in the same boat would have
had the cost of finding the place to patch. The patch itself wasn't the
effort, finding where to fit it in was.

The "virus" nature of GPL is only if someone decides to use the existing
work. They can start from scratch and be "clean", but they have to put in
all the work. That's the "cost" of "open source", if you benefit from it,
then others must benefit.

Meanwhile, the whole point of "open source" is "I have no idea what you
will do with this, but it costs me nothing, so I will release it".
Sometimes that's generosity, sometimes it's "well I can't make money from
this". There must be endless programs that people have "let go" because
it's too obscure and won't make money, yet by releasing, it can find it's
way to the relative handful who can actually make use of it. If I had
been able to release that assembler patch, the best I could do was write a
shrot article for one of the magazines. I couldn't expect to sell it for
much, and the cost of sending it out would become an issue (back when it
would go out by real mail)

Michael