I am running 32bit ubuntu on 64bit x86 processor (intel). I know that the word size is 64bits in this case but I am little confused about the 32bit OS.
So while I calculate the memory bandwidth, shall I assume that the data bus width of 64 lines will be used and it will exhibit the same performance as the 64bit OS? IOW, I want to better understand the relation between OS width on the architecture width.
For instance, a 64bit operand can be read in single shot with a 64bit wide memory bus. Does this need the support of 64bit OS? With a 32bit OS, will it make two reads (32bits each time) to read the 64bit operand?
Thanks!
You shouldn't worry about this.
OS 32-bit vs. 64 bit is deffer only on memory addressing. IN 64-bit you may addres more.
Data loading from memory is independent from OS - it depends on processor architecture.
Better processor may load 128, 256 bits at one memory load.
It is shortest explanation and should be true in 99,9% of programs running on this OS.
0,1% if reserved for programs, that doesn't care about memory aligment when accessing data. But this problem may be addressed in next 99,9% by processor cache.
Summarizing - you shouldn't worry if your OS has enough memory to run all programs.
Applications compiled for a 32 bit OS don't even know that the bus is 64bits large, they will always use the first 32bits only.
Because the processor is NOT running in 64bits mode, your 64bits data will be stored in two distinct registers (say EAX:EDX), reading two distinct parts of the same number, using the first 32bits of the bus.
Related
Actually I want to link 64 bit library to my 32 bit application.
I want to use a library which works faster under 64 bits under some circumstances. But i have to link that library to my 32 bit application . Is it possible or not ??
In a word, no. The only way to get compiled 64bit code talking to compiled 32bit code is via some form of IPC (e.g. pipe, named pipe, or network connection). That may well introduce performance bottlenecks of its own, so probably isn't worth the bother.
It is not easy as #robthebloke mentioned. But NVIDIA RTX Remix Runtime does it somehow, making older 32bit games running on 64-bit vulkan driver (bypassing 2-4GB virtual memory limit).
I have try to change in bios setting but cannot find it
my laptop type hp430
From the screenshot I see that you use a 32-bit version of Windows 7. Note that 32-bit versions of Windows can use up to 3GB or RAM in most cases. You then subtract from that the amount of memory allocated for the integrated graphics card and you get the total amount of RAM usable by the system. If you want your computer to be able to use 4GB RAM or more, I recommend installing a 64-bit version of Windows.
Regarding changing the memory allocated for Intel HD Graphics, unfortunately it's rarely possible to do this on laptops, but I recommend you check out your BIOS thoroughly as this article recommends. You can also try to contact your laptop's manufacturer and ask him whether this is possible or not.
Is it possible to enable OpenCL on an A10-7800 without using it for the X server? I have a Linux box that I use for GPGPU programming. A discrete GEForce 740 card is used for both the X server and running OpenCL & Cuda programs I develop. I would also like the option of running OpenCL code on the APU's integrated GPU cores.
Everything I've read so far implies that if I want to use the APU for OpenCL, I have to install Catalyst and, AFAIK, that means using it for the X server. Is this true? Would there be an advantage to using the APU for my X server and using the GEForce solely for GPGPU code?
I had a similar goal, so I've built a system with AMD APU (4 regular cores + 6 GPUs) and Nvidia discrete graphics board. Sorry to say it wasn't easy to make it work, so I asked a question on the Ask Ubuntu forum, didn't get any answers, experimented a lot with hardware and software setup, and finally have posted my own answer to my question.
I'll describe my setup again here - who knows, what might happen with my auto-answered question on the Ask Ubuntu?
At first, I had to enable the integrated graphics hardware via a BIOS flag. This flag is called IGFX Multi-Monitor on my motherboard (ASUS A88X-PRO).
The second step was to find a right mix of a low-level graphics driver and high-level OpenCL implementation. The low-level driver for AMD processors is called AMD Catalyst and has a file name fglrx. I didn't install this driver from the Ubuntu software center - instead I used a version 15.302, directly downloaded from the AMD site. I had to install a significant number of prerequisites for this driver. The most important finding was that I had to skip running the aticonfig command after the fglrx installation - this command actually configures the X server to use this driver for graphics output, and I didn't want that.
Then I've installed the AMD SDK Ver 3.0 (release 130.136, earlier releases didn't work with my fglrx) - it's the OpenCL implementation from AMD. The clinfo command reports both CPUs and GPUs with correct number of cores now.
So, I have a hybrid AMD processor, supported by the OpenCL, with all the graphics output, supported by a discrete graphics card with Nvidia processor.
Good luck!
I maintain a Linux server (OpenSUSE, but the distribution shouldn't matter) containing both NVIDIA and (a discrete) AMD GPU. It's headless, so technically I do not know whether the X server will create additional problems, but I don't think so. You can always configure xorg.conf to use exactly the driver you want. Or for that matter: install Catalyst, but delete the X server driver file itself, which is not the same thing that you need for OpenCL.
There is one problem with a mixed-vendor system that I noticed, however: AMDs OpenCL driver (ICD) will go spelunking for a libGL.so library, I guess in order to do OpenCL/OpenGL-interop. If it finds any of the NVIDIA-supplied libGL.so's, it will get confused and hang - at least on my machine. I "solved" this by deleting all libGL.so's (I do not need it on a headless compute server), but that might not be an acceptable solution for you. Maybe you can arrange things such that the AMD-supplied libGL.so's take precedence, possibly by installing the AMD driver last.
I'm a beginner programmer in my first year of Computer Science.
I'm curious about the 32 bit and 64 bit systems, and how it affects developing software.
When I download software I need to choose between the two, while other software only has a 32 bit version.
Are there different ways of programming for a 64 bit system?
Is it compiled in the same way?
What are the main benefits of a separate 64 bit app?
Cheers
Are there different ways of programming for a 64 bit system?
Yes and no. No, in the sense that most of the time you should be able to write platform-independent code, even if you are coding in a language like C. Yes, in the sense that having knowledge of the underlying architecture (not just the word size!) helps to speed up critical parts of your program. For instance, you may be able to use special instructions available.
Is it compiled in the same way?
Again, yes and no. Compilers for systems languages work in similar ways for all architectures, but of course, the details differ a bit. For instance, the compiler will use knowledge about your architecture to generate as efficient code as possible for it, but also has to take care of differences between architectures and other details, like calling conventions.
What are the main benefits of a separate 64 bit app?
I assume you are asking about the usual desktop CPUs, i.e. x86 architecture, but note that there are other architectures with word sizes ranging from 8-bit to 128-bit. Typically, people would compile a program targeting a single architecture (i.e. for a given machine), and that's about it.
However, x86 is a bit special, in that the CPU can operate in different modes, each with a different word size: 16-bit, 32-bit and 64-bit (among other differences). Effectively, they implement several ISAs (Instruction Set Architectures) in a single CPU.
This was done to preserve backwards compatibility, and it is key to their commercial success. Consider that, when people bought the first 64-bit capable CPUs, it was most likely that they were still using 32-bit operating systems and software, so they really needed the compatibility. The other options are emulating it (poor performance) or making sure all the popular customer software has been ported (hard to achieve in ecosystems like Windows with many independent, proprietary vendors).
There are several benefits of 64-bit x86 over 32-bit x86: more addressable memory, more integer registers, twice the XMM registers, a better calling convention, guaranteed SSE2... The only downside is using 64-bit pointers, which implies more memory and cache usage. In practice, many programs can expect to be slightly faster in x64 (e.g. 10%), but pointer-heavy programs may even see a decrease in performance.
Generally speaking the main benefit of 64 bit application is that it has access to more memory. Having 32 bit pointer you can access only 4GB of memory.
Most modern compilers have option to compile either 32 bit or 64 bit code.
32/64 coding is the same unless you are dealing with huge in-memory objects, where you would need to use 64 bit specifically.
An interesting fact/example is that Unix time is stored as a single number. It is calculated as a number of seconds passed from January 1st 1970. This number will soon reach 32-bit size, so eventually we will have to upgrade all of our systems to 64-bit so they can hold such a large number.
I am creating a quite simple application which reads and display text files and search through them.
I am asking myself if there is any interest for me to propose 32 and 64 bits version to the user.
Is the difference only in having access to more memory heap size with the 64 bit version or is there any other interest ?
Will a 32 bit compiled program work on a 64 bits JVM (I assume yes)
The only differences between 32-bit and 64-bit builds of any program are the sizes of machine words, the amount of addressable memory, and the Operating System ABI in use. With Java, the language specification means that the differences in machine word size and OS ABI should not matter at all unless you're using native code as well. (Native code must be built to be the same as the word-size of the JVM that will load it; you can't mix 32-bit and 64-bit builds in the same process without very exotic coding indeed, and you shouldn't be doing that with Java about.)
The only times that have swung it for me is when there have been native libraries involved that have pushed it one way or the other. If you're just in Java land then realistically, unless you need >4GB of heap size, there's very little difference.
EDIT: The differences include things like it uses slightly more memory than 32 bit, significantly more if you're using a version before 6u23 and aren't using -XX:+UseCompressedOops. There may also be a slight performance difference between the two, but again nothing huge.