31

I'm trying to get TensorFlow up on my Chromebook, not the best place, I know, but I just want to get a feel for it. I haven't done much work in the Python dev environment, or in any dev environment for that matter, so bear with me. After figuring out pip, I installed TensorFlow and tried to import it, receiving this error:

Python 3.5.2 (default, Nov 23 2017, 16:37:01) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import tensorflow as tf
2018-12-11 06:09:54.960546: F tensorflow/core/platform/cpu_feature_guard.cc:37] The TensorFlow library was compiled to use AVX instructions, but these aren't available on your machine.
Aborted (core dumped)

After some research, I have discovered that my processor (an Intel Celeron N2840 (Bay Trail-M Architecture)) does not support AVX instructions, so I was wondering if there was a way to use a version compiled for some other instruction set. Cog tells me I can use MMX and various SSEs (whatever the hell that means).

P.S. This is sort of a duplicate of TensorFlow error using AVX instructions on Linux while working on Windows on the same machine but not entirely. Plus I can't comment because I don't have 50 reputation.

P.P.S. I looked at How to compile Tensorflow with SSE4.2 and AVX instructions? and got scared

bobe
  • 432
  • 1
  • 5
  • 11
  • If you don't mind using an older version, TF wasn't compiled with AVX instructions up until version 1.5, so if you install that one you'll be aleto try out some stuff (and miss out on *a lot* more) – GPhilo Dec 11 '18 at 11:33
  • Otherwise, you'll either need to build it from source or try search for an unoffical wheel from someone, since TF now only supports CPUs with AVX – GPhilo Dec 11 '18 at 11:34
  • @GPhilo Would I be able to get a previous version via pip, or would I need to use something else? – bobe Dec 11 '18 at 11:38
  • 2
    `pip install tensorflow=1.5` – GPhilo Dec 11 '18 at 11:39
  • 7
    @GPhilo You're missing an equals: `pip install tensorflow==1.5` – Desty Jan 06 '19 at 03:42
  • True that, I never remember if I need just one or two there – GPhilo Jan 06 '19 at 08:58

3 Answers3

5

A best practices approach suggested by peter-cordes is to see what gcc is going to make of your 'what capabilities your cpu has' by issuing the following:

gcc -O3 -fverbose-asm -march=native -xc /dev/null -S -o- | less

This command will provide information (all) about your cpu capabilities from the view of gcc, whom is going to do the build, so gcc's view matters.

When does this come up? When a program offers to tailor itself to your cpu. Dang. What do I know about my cpu. Well, the above line will tell you all you need to know.

That said, generally, people/developers that are promoting cpu based capabilities will state or suggest a list of things that go faster/better/stronger if your cpu has *. And the above will give you *. Read carefully what you see. If you don't have it, you don't want it, i.e.

-mno-avx(whatever you don't want;in my case it was avx)

A good overview of install of CPU capable on older cpu(s) is provided by Mikael Fernandez Simalango for Ubuntu 16.04 LTS. It assumes a python2.7 environ but easily translates to python3. The heart of the matter is extracting which cpu instruction extensions are available on your particular cpu that will be used in addition to -march=native via /proc/cpuinfo, (but note, it appears limited to what flags it accepts, so may be better to actually read through the instruction above and reflect)

grep flags -m1 /proc/cpuinfo | cut -d ":" -f 2 | tr '[:upper:]' 
'[:lower:]' | { read FLAGS; OPT="-march=native"; for flag in $FLAGS; 
do case "$flag" in "sse4_1" | "sse4_2" | "ssse3" | "fma" | "cx16" | 
"popcnt" | "avx" | "avx2") OPT+=" -m$flag";; esac; done; 
MODOPT=${OPT//_/\.}; echo "$MODOPT"; }

Running this on my old box output:

-march=native -mssse3 -mcx16 -msse4.1 -msse4.2 -mpopcnt

It gets part way there. What is not clear is how to say, 'not this' and 'not that', which for old CPUs would be, most likely, -mno-avx.

For an old cpu, which -march matters and Nephanth very usefully addresses this:

gcc -march=native -Q --help=target|grep march

produces

-march=                             westmere

which means my response to the ./compile question should be or might be, and note the quotes 'westmere' which is also in the gcc docs so the ' ' must be there for a reason

-march='westmere' -mssse3 -mcx16 -msse4.1 -msse4.2 -mpopcnt -mno-avx

but this is probably much better (see discussion below):

-march=native -mssse3 -mcx16 -msse4.1 -msse4.2 -mpopcnt -mno-avx

The -mno-avx is an option for gcc, and results, after many hours, in 

Python 3.5.2 (default, Nov 23 2017, 16:37:01) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import tensorflow as tf
>>> 
>>> tf.__version__
'2.0.0-alpha0'

which looks like success.

Restated: In either order, find out what instructions are (or not) supported by your cpu, and state those explicitly.

Chris
  • 1,647
  • 1
  • 18
  • 25
  • If `-march=native` worked correctly for TensorFlow's `bazel` build script, that's all you'd need. It implies the other `-m` options on targets that support them. The fact that it doesn't work on its own means the build script must be eating it (and/or `-mtune=native`, too), and not passing it through to GCC like args that don't contain an `=`. – Peter Cordes Mar 14 '19 at 20:33
  • @user:224132 And indeed, the mystery continues, and I find myself entertaining another build, wherein it appears that something on the order of negatively stating what can't or shouldn't be done needs to be stated also, on the order of -mnoavx2, as my current build failed and I feel I should remove my answer. The construction of the configure file is remarkably unhelpful in this instance, at lease coming from more of a Make mind set, – Chris Mar 14 '19 at 23:41
  • I downloaded bazel a while ago to have a look at debugging TensorFlow's build script, but it was just layer upon layer of scripts. Since I don't use TensorFlow myself, I got bored and stopped. – Peter Cordes Mar 14 '19 at 23:49
  • On reflection, gcc won't do the mining to determine what native is as that implies tests, so native is probably a placeholder awaiting specificity arrived at by other means. – Chris Mar 26 '19 at 01:49
  • No, `-march=native` does work reliably, and does enable all the `-m` options supported by the CPU you're compiling on. If you run `gcc -O3 -fverbose-asm -march=native -xc /dev/null -S -o- | less` (compile an empty file as C, piping the asm output to stdout) you'll see asm comments showing which options were enabled/disabled. e.g. on my Skylake CPU, it shows `-mavx2 -mfma -mbmi2` plus many many other things, along with detecting tuning settings like `--param l1-cache-size=32 --param l1-cache-line-size=64`. Presumably it uses the `cpuid` instruction to check CPU feature bits and cache. – Peter Cordes Mar 26 '19 at 02:10
  • ok, just ran it, `gcc -O3 -fverbose-asm -march=native -xc /dev/null -S -o- | less`, you are correct and my opine is unfounded. None the less, my install didn't go until I replaced native with westmere, unaccountably. – Chris Mar 26 '19 at 02:20
  • In your answer, you mention `-mno-avx`. Yes, that's the correct option. e.g. `gcc -march=skylake -mno-avx` would disable AVX1/AVX2, and FMA because that depends on AVX. (But it would still use BMI2 instructions like `shlx` that use a VEX encoding, and aren't supported on westmere.) I don't know why `-march=westmere` would work when `-march=native` doesn't. Neither one *disables* earlier `-m` options. e.g. `-mfma -march=westmere` enables FMA and AVX, along with popcnt and other Nehalem stuff. – Peter Cordes Mar 26 '19 at 02:42
  • So more likely it's not `-march=westmere` vs. `-march=native` that matters, it's your `-mno-avx` that will override something the build script is adding to gcc options before these extra options. Unless your system is weird and `-march=native` really is broken? Or you're cross-compiling from a machine with a newer CPU? Did you test `-march=native -mno-avx` before concluding that `-march=westmere -mno-avx` was necessary? Also, any quoting like `-march='westmere'` will be removed by the shell before gcc sees it. The build script is probably a mess, and that's the problem, not gcc. – Peter Cordes Mar 26 '19 at 02:47
  • For our discussion purposes, my approach would be inconclusive as to `-march=native` or `march=westmere` because at point of successful build I also stipulated -mno-avx. And to your point, -mno-avx probably was sufficient to the task and `-march=westmere` as an unnecessary specificity. But overall, I hope that people get a sense of an approach, or process, to arrive at their goal of install, be it a current Chrome tablet or an ancient cpu. Thank you for continuing to engage and guide my thinking here, it has be valuable to me, and hopefully others. – Chris Mar 27 '19 at 00:18
  • Ok, if the first time you tried `-mno-avx` was with `-march=westmere`, then that was pretty definitely the trick. Presumably the build script uses `-mavx` (or something that implies it) *before* these user-supplied options. You should probably update your answer to say that, because the part about needing westmere instead of native, and about single quotes, doesn't look correct at all. (I still upvoted because it's useful and not actively harmful; `-march=westmere` is as good as `-march=native` on a Nehalem/Westmere CPU. But not good on a Core2 or K10 or something!) – Peter Cordes Mar 27 '19 at 00:23
  • which is also why it is Nehalem/Westmere and not Core2 or Core3, which were a couple of build 'rabbit holes' I also climbed down. But truth is, as I understand, Tensorflow build/make is explicitly tilted to `-mavx`, i.e. appears to be baked in, though confess I haven't scanned build to confirm. But, as this discussion should make clear, all cpu(s) are local, even native. – Chris Mar 27 '19 at 00:34
  • My point is that for future readers with a different CPU than you, `-march=native -mno-avx` is safe on a Core2 or K10, but `-march=westmere -mno-avx` is not; it would enable SSE4.1 and `popcnt`, possibly leading to illegal-instruction faults. (I don't know what else the TensorFlow build script might implicitly enable; hopefully just AVX) – Peter Cordes Mar 27 '19 at 00:56
  • The best I've been able to suggest is that people employ your gcc /dev/null and actively think about what is either require or might be achieved on a given install, and have attempted to edit the above to reflect both this system of comments and their useful information to others. Give thumbs up or not, but I think I've given proper gist. – Chris Mar 27 '19 at 01:06
1

Try Anaconda. It should have TensorFlow distribution for old CPUs. Compilation of TensorFlow is difficult.

FooBar167
  • 2,721
  • 1
  • 26
  • 37
0

You can find pre-built wheels(support for windows) here on Github : https://github.com/fo40225/tensorflow-windows-wheel or you can build your own wheels

I had the same issue too but i got it resolved.

BrigaDella
  • 131
  • 9