I'm trying to install a modern version lapack (3.8.0) on my Centos 6.6 machine. The directions say
Ideally, a highly optimized version of the BLAS library already exists on your machine.
My version of blas was downloaded through yum:
$ yum info blas
Loaded plugins: fastestmirror, refresh-packagekit, security
Loading mirror speeds from cached hostfile
* base: mirror.cogentco.com
* epel: mirror.cogentco.com
* extras: mirror.web-ster.com
* updates: mirrors.maine.edu
Installed Packages
Name : blas
Arch : x86_64
Version : 3.2.1
Release : 5.el6
Size : 710 k
Repo : installed
From repo : base
Summary : The Basic Linear Algebra Subprograms library
URL : http://www.netlib.org/lapack/
License : BSD
Description : BLAS (Basic Linear Algebra Subprograms) is a standard library which
: provides a number of basic algorithms for numerical algebra.
How do I know if this is 'highly' optimized for my machine?
Easy, really. They are not as optimized as they could be. I always build them for the specific machine, I need them on. The runtime differences are considerable. I just compared OpenBLAS as shipped with Ubuntu 18.04 and the one I built on my own.
The dgemm exhibits a runtime difference of in average 25%; zgemm is roughly 38% faster, with the self compiled libraries. This is harmless yet. dgesvd is even nearly twice as fast.
Related
Does anyone know if it is possible to install lustre client software on a linux machine that has kernel 4+? From what I have experimented so far, all the working examples are on kernel 3.10. And if I try to install kmod-luster-client on 4+ machine, it fails with:
rpm -ivh kmod-lustre-client-2.10.5-1.el7.x86_64.rpm
error: Failed dependencies:
kernel < 3.10.0-863 is needed by kmod-lustre-client-2.10.5-1.el7.x86_64
kernel(PDE_DATA) = 0x44f0d59d is needed by kmod-lustre-client-2.10.5-1.el7.x86_64
According to lustre/ChangeLog in the b2_10 branch, it works with kernels at least 4.4.133-94.33 (SLES12SP3) and 4.4.0-131 (Ubuntu 16.04).
If you are using a newer kernel, you also need to use a newer version of Lustre. The lustre/ChangeLog on the tip of master (almost 2.12 release) reports support for kernels 4.15.0-32 (Ubuntu 18.04).
It looks like you are trying to install a binary kernel module RPM built for the RHEL7 kernel on a non-RHEL kernel. That is never going to work. You need to either get the right RPMs/Debs for your kernel from https://lustre.org/download/ or download the source and rebuild it for your kernel.
The 2.10.x kernels are currently the LTS maintained releases (bugfixes backported to that release), while 2.11.0 is a feature release that does not have bugfixes backported.
I'm looking for a way to get a working Common Lisp compiler in CentOS 7.
It seems that neither base or EPEL repos contain any of the widely available open-source Lisp compilers. There are bits of info regarding CLISP and SBCL on CentOS 6 but none about any compiler on CentOS 7.
Am I missing something here or has the switch from RHEL6 to RHEL7 completely forgot about CL compilers ?
It's often better to get Common Lisp systems directly than from a distribution's package system. The package system lags behind, and the library model of Common Lisp does not lend itself well to packages.
You can download an SBCL binary from http://www.sbcl.org/
You can get Clozure CL from http://ccl.clozure.com/
Other implementations are available in similar ways, but those two are the best.
I am sure yum install sbcl clisp will work:
$ yum search sbcl
Failed to set locale, defaulting to C
Loaded plugins: fastestmirror, refresh-packagekit, security
Loading mirror speeds from cached hostfile
* base: centos.mirror.nac.net
* epel: mirrors.einstein.yu.edu
* extras: reflector.westga.edu
* updates: mirror.es.its.nyu.edu
========================================== N/S Matched: sbcl
maxima-runtime-sbcl.x86_64 : Maxima compiled with SBCL
sbcl.x86_64 : Steel Bank Common Lisp
Name and summary matches only, use "search all" for everything.
SBCL is available in EPEL7: https://dl.fedoraproject.org/pub/epel/7/x86_64/repoview/sbcl.html
(I guess it wasn't yet provided when this question was originally asked, but at least at the time of writing this it's there.)
There is a COPR-Repo for EPEL7: https://copr.fedoraproject.org/coprs/shassard/sbcl/
Maybe you like to try this one?
I am able to install SBCL on Amazon EC-2 - CentOS 7 using the following command:
wget https://copr-be.cloud.fedoraproject.org/results/shassard/sbcl/epel-7-x86_64/sbcl-1.2.9-1.el7.centos/sbcl-1.2.9-1.el7.centos.x86_64.rpm
sudo rpm -Uvh sbcl-1.2.9-1.el7.centos.x86_64.rpm
Note: I wasn't able to run "sudo yum install SBCL"
what is different between the following type i get qemu-kvm ? boths are use centos 6.4.
yum install qemu-kvm ,then show the version:
[root#centos6 qemu-kvm]# /usr/local/bin/qemu-system-x86_64 --version
QEMU emulator version 1.2.50 (qemu-kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard
get the source code and build it by gcc.
[root#centos6 qemu-kvm]# /usr/libexec/qemu-kvm --version
QEMU PC emulator version 0.12.1 (qemu-kvm-0.12.1.2), Copyright (c) 2003-2008 Fabrice Bellard
Qemu uses 2 kinds of cpu virtualization, TCG (tiny code generator) and KVM. TCG emulates all instruction of guest code with plain c code, it translates guest code to host code in real-time. While KVM lets the host directly runs guest code, KVM requires the guest and the host to have the same instruction set (basically, the same cpu), not every cpu can do this, for intel cpus, it requires VMX feature. Which I assume you have understood these.
Qemu-kvm is obsolete, KVM comes with QEMU now if you download the latest code, you just have to compile it with "--enable-kvm" option. Your QEMU source code is very old, the latest version of QEMU is AFAIK, 1.7.
Your yum source provide 1.2.50 version of qemu. Try "yum install qemu", and try running with -enable-kvm if you don't want to build from source code (I haven't tried though)..
Qemu is Hypervisor.
KVM isn't. It is an accelerator(linux module which does the code translation fast) and used with Qemu, because Qemu when used with TCG is slow.
I am having difficulty on my server trying to get the selftest.py to run successfully.
I am trying to get PIL 1.1.7 working with Python 2.4.4 (Are the versions compatible?)
When the install is preformed like so:
# python2.4 setup.py install
running install
running build
running build_py
running build_ext
--------------------------------------------------------------------
PIL 1.1.7 SETUP SUMMARY
--------------------------------------------------------------------
version 1.1.7
platform linux2 2.4.6 (#1, Dec 21 2012, 14:54:30)
[GCC 4.4.6 20120305 (Red Hat 4.4.6-4)]
--------------------------------------------------------------------
*** TKINTER support not available
--- JPEG support available
--- ZLIB (PNG/ZIP) support available
--- FREETYPE2 support available
*** LITTLECMS support not available
--------------------------------------------------------------------
To add a missing option, make sure you have the required
library, and set the corresponding ROOT variable in the
setup.py script.
To check the build, run the selftest.py script.
running build_scripts
running install_lib
running install_scripts
changing mode of /usr/local/bin/pilconvert.py to 755
changing mode of /usr/local/bin/pilprint.py to 755
changing mode of /usr/local/bin/pilfile.py to 755
changing mode of /usr/local/bin/pilfont.py to 755
changing mode of /usr/local/bin/pildriver.py to 755
creating /usr/local/lib/python2.4/site-packages/PIL.pth
Everything seems handy dandy. Jpeg support is available and all is happy. But the selftest.py however is a different story:
# python2.4 /usr/local/src/Imaging-1.1.7/selftest.py
--------------------------------------------------------------------
PIL 1.1.7 TEST SUMMARY rc/Imaging-1.1.7]# yum install libjpeg62-devel zlib1g-devel libfreetype6-devel liblcms1-develp
--------------------------------------------------------------------
Python modules loaded from ./PIL
Binary modules loaded from ./PIL
--------------------------------------------------------------------
--- PIL CORE support ok
*** TKINTER support not installed
*** JPEG support not installed
*** ZLIB (PNG/ZIP) support not installed
--- FREETYPE2 support ok
*** LITTLECMS support not installed
--------------------------------------------------------------------
Running selftest:
*****************************************************************
Failure in example:
try:
_info(Image.open(os.path.join(ROOT, "Images/lena.jpg")))
except IOError, v:
print v
from line #24 of selftest.testimage
Expected: ('JPEG', 'RGB', (128, 128))
Got: decoder jpeg not available
1 items had failures:
1 of 57 in selftest.testimage
***Test Failed*** 1 failures.
*** 1 tests of 57 failed.
I get the dreaded Jpeg decoder not available.
I've tried a variety of things. I changed the setup to point to usr/lib64 that didn't work. I made some symbolic links in the usr/lib to point to the libjpeg.so file, that also didn't work. I went back and forth with the tech guys at our server hosting place and they aren't understanding the issue and it's like talking to a wall. I am really stuck. The only thing I haven't tried is the PiP but I didn't try that because I don't know how that works exactly. So I want to avoid that.
Is there a compatibility issue or a setting I just don't have quite right?
Thank you for the assistance.
--UPDATE--
Working on this problem again these days
I've tested Centos 5 & 6 32-bit And everything installs like a charm, but 64-bit I'm still having issues.
It seems like the selftest works with the stock python2.6 but not with python2.4. Pil 1.1.7 is compatable with 2.4.4 but I think there is a problem with the libraries in 64-bit. Still searching for a solution.
After extensive testing it's just not possible.
I'm sure it can be done but the steps it would require to get it down would be so intensive that it would make it difficult to gaurentee the stability of the server/system.
The problem really lies in the 64-bit system. The Python-Imagining would work with python 2.4 if python 2.4 was compiled as 32-bit. However even if you get Python-2.4 compiled into 32-bit it has a hard time with the libraries since everything in Centos is build for the 64 arch. And getting those additional libraries is cumbersome since the repos won't include the structures you need to get it working. It's just, annoying. It's not feasible to go hunting around in circles and the time spent trying to support such a limping system is wasted. And possibly puts the system at risk.
No, it's not possible to install PIL for Python 2.4 on a 64-bit machine.
In my case we had no support of all the libraries in PIL (CentOS 6, x64)
*** TKINTER support not available
*** JPEG support not available
--- ZLIB (PNG/ZIP) support available
*** FREETYPE2 support not available
*** LITTLECMS support not available
So we used following:
yum install freetype freetype-devel libpng libpng-devel libjpeg libjpeg-devel
And now we have
*** TKINTER support not available
--- JPEG support available
--- ZLIB (PNG/ZIP) support available
--- FREETYPE2 support available
*** LITTLECMS support not available
3 years later, I know, but this can work just fine! The standard build process will not look for libraries in /usr/lib64, but you can't specify a library path when running setup.py build, so you need to rebuild the binaries afterwards in a separate step:
yum install freetype-devel libpng-devel libjpeg-turbo-devel libzip-devel lcms-devel
pip download PIL
unzip pil-1.1.7.zip
cd pil-1.1.7
./setup.py build
./setup.py build_ext -L /usr/lib64/:/usr/local/lib64 --force
./setup.py install --prefix /usr/local/python27 --force --skip-build
This is on Scientific Linux 6.7 64-bit, using Python 2.7 compiled from source.
I don't want to install all as it consumes much space..
the following is what i'm sure is needed:
gcc, make python..
what else?
On the site, in their documentation on installing...
http://www.shogun-toolbox.org/doc/en/current/installation.html
Requirements
SHOGUN requires the standard linux utils like bash, grep, test, sed,
cut, ldd, uname gcc g++ and cat python (debian package: python2.4 or
python2.5) for the ./configure to work.
Optionally you will need atlas and lapack (debian packages
lapack3-dev, atlas3-headers atlas3-base-dev or atlas3-altivec-dev
atlas3-sse2-dev) installed. Note that atlas/lapack is only supported
under linux (high performance computing should be done under linux
only anyway). In case atlas/lapack is unavailable, don't worry most of
shogun will work without, though slightly slower versions are used.
To
enable Multiple Kernel Learning with CPLEX(tm) just make sure cplex
can be found in the PATH. If it is not found shogun will resort to
GLPK (if version at least 4.29 is found) for 1-norm MKL, p-norm MKL
with p>1 will work nonetheless.
To compile the C# interface you need to have the C# developer files
(debian package mono-utils) installed.
To compile the Lua interface
you need to have the Lua developer files (debian package lua)
installed.
To compile the Java interface you need to have the Java
developer files (debian package openjdk-6-jdk) installed.
To compile
the R interface you need to have the R developer files (debian package
r-base-dev) installed.
To compile the Ruby interface you need to have
the Ruby developer files (debian package ruby) installed.
To compile
the octave interface you need to have the octave developer files
(debian package octave3.0-headers) installed.
To compile the python
interface you need to have numpy version 1.x installed (debian package
python-numpy) installed.