I have complied TensorFLow to support my Atom processor. For my LeMe Quieter2Q I used -march=goldmont-plus. This is taking ages on my computer. I'm wondering if this also can be executed on a different Atom processor of an earlier generation. I had one, and used -march=silvermont, before.
Since this is for an open source project, I'm wondering if I can provide now a pre-built binary for any Atom processor or if this has to be redone for an Atom processor using the silvermont or different architecture. If my passed parameter is too specific for this Atom processor, I have to rebuild it again to be more generic.
Related
I have a Laptop with Intel(R) HD Graphics 520 GPU in it. I added OpenCL developer package to Cygwin. I have found a small Mandelbrot-set calculator program for OpenCL in C on GitHub. It is for Apple, so I modified the Makefile to use the proper headers and settings for gcc. Now the code compiles and executes nicely (bmp file created):
$ ./mandelbrot.exe
Device 0: GenuineIntel pthread-Intel(R) Core(TM) i5-6300U CPU # 2.40GHz
I have two questions:
#1. How can I add (if it is possible) the Intel GPU to the /etc/OpenCL/vendors list? I tried to install from Intel site the Intel CPU runtime for OpenCL Applications for Windows OS and Intel Graphics Technology driver package, but I do not know where can I find the proper OpenCL dll I can point in the intel.idc file.
#2. In /etc/OpenCL/vendors I have found a pocl.icd file pointing to cygpocl-2.dll. I assume this is the pthread library. But it seems to me it is running only a single thread, although I have 4 cores. Should I do any modification to run it in multiple threads? I debugged the code and it seems that as there are only one device found, so it runs only on one thread. In the initialization function it sets the device_work_size property for processing a stirp per device of the final bmp. But as there is only one device, the whole bmp is processed by one run (one clEnqueueNDRangeKernel and one clEnqueueReadBuffer is called).
UPDATE
I have installed Intel(R) Graphics – Windows* DCH Drivers. It installed graphics drivers. I have found the intelocl64.dll (as /cygdrive/c/Program Files (x86)/Common Files/Intel/Shared Libraries/intel64/intelocl64.dll). I put this whole path into /etc/OpenCL/vendors/intel.icd file. So far, so good. Now it cannot even find pthread device... Bah...
I don't think it is possible to use the GPU from cygwin. I would recommend to either build a native Windows binary (e.g. with Visual Studio or Intel DPC++) or use WSL. See https://github.com/intel/compute-runtime/blob/master/WSL.md for requirements.
I am currently taking a class on Assembly Language and Computer Architecture. We're programming in MASM for x86 processors. I have a Macbook Air, so of course I have to run Windows on a virtual machine to program in MASM for our assignments.
What I'm confused about: We're learning about, and programming for x86 architecture. When I looked up my Macbook Air's processor, it seemed to be in the x86 family. Considering that, why doesn't MASM work with Mac OS X?
Furthermore, if assembly language communicates directly w/ hardware, why does merely installing the Windows OS (or running it through a VM) on Apple Hardware suddenly allow me to program in MASM?
Thanks,
Ian
[EDIT for clarification: My understanding -- please tell me if i'm wrong -- is that Assembly Language is as "low as you can go." I.e. it's pre-operating system, and provides instructions directly to the hardware itself. Thus, I don't understand why an assembly language for x86 architecture doesn't work on ALL x86 machines, regardless of OS]
Programs are made up of more than just the raw machine code. The executable needs to have a special format that the OS can understand, so it can load and run the code. Also, the code expects a certain environment, such as libraries and system calls (along with the appropriate calling conventions).
To compile and run your assembly program you need to assemble it first, that is run it through MASM in this case. However, MASM itself is a windows executable. It is in the executable format for windows, and it uses libraries and operating system functions accordingly. As such, you can't run it directly on mac os. Afterwards, you typically also need to link your code, which has the same issues. The next problem is with the program itself. MASM (and the rest of the toolchain) is by default also targeting windows (or dos) and so the created program has the appropriate format.
You can theoretically create a program intended to run on mac os using windows and masm. This is called cross-compiling in general. If your toolchain does not support the required mac format, you will need to create everything by hand. You obviously also need to write your program such that it expects the mac environment. For example, you can't use dos interrupts or windows libraries.
Since the architecture is the same, you don't need to virtualize the cpu. You can get away with emulating just the environment. An example for this is the windows emulator, wine, or cygwin emulating unix on windows.
A very rough analogy: there are human languages that use the same alphabet, but you still need to translate. There are also languages that do not even use the same alphabet, or don't even have letters. You will need to do more work in these cases.
I try to understand this whole "compiling" topic in a way more detailed than all those "what is a compiler (doing)?" articles out there.
One big question to me is processor- and os-platform dependency when compiling directly to machine code (e.g. C). I try to formulate concrete questions that needs to be resolved in order to get my picture clearer:
I compile my C code via gcc on a Linux distribution... :
Can I run the resulting executable on any other Linux Distribution?
Is that executable bound the processor platform compiled on? Do I need to search for another e.g. power-pc gcc when I am running a x86 distro?
Can I somehow execute this on windows? I know executables differs but the binary code is the same, isn't it?
So in the end my questions aims on: Is compiling about targeting a specifiy OS paltform, processor platform or both?
Thanks!
Compiling targets both, OS, and Architecture.
The OS needs to be targeted because:
The format of what is an "executable" file is different among operating systems.
Programs call the operating system even for common tasks like writing to the console, reading from a file, or terminating cleanly (standards like POSIX mitigate OS dependencies by defining a common layer between the program and the OS).
The CPU architecture must be targeted because the CPU instructions are different, even among different generations of the "same architecture".
Can I run the resulting executable on any other Linux Distribution?
In general, Yes, but on specific cases it may depend on the type of program (f.i. GUI) and the services assumed available on the OS.
Is that executable bound the the processor platform compiled on? Do I need to search for another e.g. power-pc gcc when I am running a x86 distro?
I don't understand what you mean by "search", but, Yes, you can cross-compile from, say, x86 targeting PPC.
Can I somehow execute this on Windows? I know executables differ but the binary code is the same, isn't it?
These days Windows has Ubuntu integration, and that allows for some kind of exceptions, but the general answer is No, because of the above.
Since I have started to learn Golang since yesterday :) I have a question about the compiled file.
Let's assume that I compile my project. It generates an .exec file in /bin folder.
Now my question is Since the file has been compiled on Mac with Intel based CPU, should it be compiled on other OS and other CPU architectures such as AMD, ARM, etc. if I want to publish it to public?
I guess this should not be problem if I'm using GO lang for my backend since I run it on a server. However, what happens if I publish my .exec file, let's say on AWS, with lots of instances that they are automatically increases/decreases based on load? Does it problem?
Edit:
This is nice solution for those how are looking Go cross compiling tool https://github.com/mitchellh/gox
The answer to the first question is yes. The current implementations of Go produce a native binary, so you will probably need a different one for Linux x86 (32-bit), Linux x64 (64-bit), and Linux ARM. You will probably need a different one for Mac OS X also. You should be able to run the 32-bit executable on a 64-bit system as long as any libraries you depend on are available in 32-bit form on that system, so you might be able to skip making a 64-bit executable.
In the future, there may be other implementations of Go that compile for a virtual machine (such as JVM or .NET), in which case you wouldn't need to compile multiple versions for different architectures. Your question is more about existing Go implementations than the language itself.
I don't know anything about AWS, but I suggest you ask that as a separate question.
Is it possible for gcc, installed on fedora 16, to cross compile for a different CPU, say SPARC?
I have build a certain understanding, need some expert to correct me if I am wrong. Different operating systems differ by the system calls they use to access the kernel or entirely by the kernel they use. IS THIS CORRECT? different kernels understands different systems calls for accessing underlying hardware. binaries or executables or programs are nothing but a bunch of system calls only. therefore every OS has its own executable. an executable meant to run to on windows wound not run on linux. by cross compiling the source code of any windown's executable we can generate executable for other OSs. word PLATFORM means operating system. POSIX are certain design standards for UNIX-like OSs.
we usually cross compile for different OSs. BUT can we cross compile for different hardware too? for example, in case of a microcontroller which does not have an OS?
No. You can't use native machine (x86) gcc for compiling program files for a different architecture. For that you require a cross-compiler-gcc that is specific to that processor architecture.
Your understanding about system calls for OS is correct. Each OS has its own set of system call which is been used by library. These libraries at the end will be translated into machine language for the processor.
Each Processor Architecture has its own set of instruction know as Instruction Set Architecture(ISA). So when a program written in high-level-language (like C) is compiled, it should be converted into machine language from its ISA. This job is done by the compiler(gcc). A compiler will be specific to only one processor architecture. For example gcc is for x86 processor. So if you want a compiler for different processor in you x86 machine you should go for a cross-compiler of that processor.
You would have to build such a version. That's part of the process of porting gcc to a new platform. You build a version that cross-compiles, then you cross-compile that version, then you test that version on the new platform, debug, rinse, and repeat.