Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Programming

An Open Source Compiler From CUDA To X86-Multicore 71

Posted by timothy
from the abstraction-gains-a-layer dept.
Gregory Diamos writes "An open source project, Ocelot, has recently released a just-in-time compiler for CUDA, allowing the same programs to be run on NVIDIA GPUs or x86 CPUs and providing an alternative to OpenCL. A description of the compiler was recently posted on the NVIDIA forums. The compiler works by translating GPU instructions to LLVM and then generating native code for any LLVM target. It has been validated against over 100 CUDA applications. All of the code is available under the New BSD license."
This discussion has been archived. No new comments can be posted.

An Open Source Compiler From CUDA To X86-Multicore

Comments Filter:
  • Alternative? (Score:5, Insightful)

    by Guspaz (556486) on Wednesday December 23, 2009 @02:11PM (#30537744)

    This isn't an alternative to CUDA; it lets CUDA code run on x86, but still doesn't do anything for AMD graphics cards. In other words, your choices as a developer are to use OpenCL and have your code run everywhere (AMD, nVidia, x86 slowly), or use CUDA and have your code run on nVidia or x86 slowly.

    What possible reason could you have to want to be locked into one GPU vendor?

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      I think Cuda was first out there, later on OpenCL occurred. And i see it as bad thing really, since that binds you to using Nvidia card. I hope it wont become popular i dont want to stick to Nvidia.(ot, when AMD has Linux drivers open sourced)

      • Re: (Score:2, Informative)

        by beelsebob (529313)

        Pardon? OpenCL does not in any way bind you to an nVidia card, it was a standard created by Apple (not nVidia) and pushed to Khronos to manage as an open standard (also not nVidia). ATI have just announced drivers for their cards for OpenCL.

        • Re:Alternative? (Score:4, Informative)

          by Sloppy (14984) on Wednesday December 23, 2009 @03:19PM (#30538428) Homepage Journal

          He means CUDA was here first, and it does(did) lock you into Nvidia. So if you jumped on the bandwagon early, your code is Nvidia only. If you waited for a standard (opencl) (or ported your app) then you're cross-platform.

          • Re: (Score:3, Informative)

            by Elbows (208758)

            On top of that, the CUDA tools are still much better than OpenCL. OpenCL is basically equivalent to CUDA's low-level "driver" interface, but it has no equivalent to the high-level interface that lets you combine host/device code in a single source, etc. CUDA also supports a subset of C++ for device code (e.g. templates), which I don't believe is the case for OpenCL. CUDA also has a debugger (of sorts), profiler, and in version 3 apparently a memory checker. But I haven't been following OpenCL that closely l

      • Re: (Score:3, Informative)

        by TeXMaster (593524)

        I think Cuda was first out there, later on OpenCL occurred.

        Yes and no. CUDA and CTM/Brook+/FireStream came to live more or less at the same time when NVIDIA and ATI realized that GPGPU (General Purpose computing on the GPU) was getting traction in the scientific computing world (originally implemented using OpenGL and shaders).

        OpenCL was essentially an effort (by Apple first and foremost, although obviously with cooperation from both NVIDIA and ATI) to get a standardized interface to SIMD multicore programming. It's actually quite close to low-level CUDA programm

        • by Trepidity (597)

          As far as I can tell, OpenCL is pretty much based on CUDA, not on an attempt to unify CUDA and CTM/Brook+/FireStream. That's partly because ATI's solutions never really caught on, and have been sorta ignored.

        • Re: (Score:2, Informative)

          by Anonymous Coward

          OpenCL isn't ALL that close either to CUDA or anything from AMD (CAL, Brook+). The status quo with AMD is that the OpenCL implementation they have is very immature e.g. doesn't support a lot of fairly basic and highly desirable OpenCL "extensions" (actually it didn't support ANY until about 2 days ago, and now they're just beta testing a few of the most rudimentary ones). Additionally there are still lots of issues with missing / unclear documentation, missing features, bugs, development / runtime platfor

          • by TeXMaster (593524)

            OpenCL isn't ALL that close either to CUDA or anything from AMD (CAL, Brook+). The status quo with AMD is that the OpenCL implementation they have is very immature e.g. doesn't support a lot of fairly basic and highly desirable OpenCL "extensions" (actually it didn't support ANY until about 2 days ago, and now they're just beta testing a few of the most rudimentary ones). Additionally there are still lots of issues with missing / unclear documentation, missing features, bugs, development / runtime platform portability issues, et. al. Most significantly, the openCL performance is still a fraction of the performance commonly achievable with Brook+ or CAL in many common scenarios on the AMD platform. This is sometimes / often true for their 58xx series boards, and pervasively so for their older 4xxx series cards (which by architectural limitations as well as by lack of planned OpenCl development toolchain support / optimization will never really perform well with OpenCL).

            On the NVIDIA side, CUDA performance and usage flexibility is still typically and substantially higher than is achievable via OpenCL, since obviously CUDA exists to fairly optimally exploit their GPU architectural capabilities whereas OpenCL is a generic GPU-vendor / architecture "neutral" platform that doesn't give as much card specific control as CUDA (or CAL in AMD's case).

            I do wonder how much this is because of OpenCL being vendor-neutral and thus 'far' from the underlying architecture, and how much it depends on the quality of the compilers. I suspect that NVIDIA does not have much of an interest in optimizing their OpenCL compiler as much as they do with their CUDA compiler, for the obvious reason that with CUDA they have vendor lock-in and can sell more hardware, whereas with OpenCL there is the (remote) possibility that a better compiler from ATI might lead people to loo

          • by DeKO (671377)

            On the NVIDIA side, CUDA performance and usage flexibility is still typically and substantially higher than is achievable via OpenCL, since obviously CUDA exists to fairly optimally exploit their GPU architectural capabilities whereas OpenCL is a generic GPU-vendor / architecture "neutral" platform that doesn't give as much card specific control as CUDA (or CAL in AMD's case).

            That's not true. I've run many equivalent CUDA and OpenCL kernels on NVIDIA cards, and they perform both the same. Pretty much in ac

    • Re: (Score:3, Interesting)

      by Yvan256 (722131)

      When did AMD drop the ATI brand?

      • Re: (Score:3, Funny)

        by mrsteveman1 (1010381)

        Wednesday December 23, @02:11PM

      • Re:Alternative? (Score:4, Insightful)

        by Guspaz (556486) on Wednesday December 23, 2009 @02:55PM (#30538198)

        Progressively more and more.

        Example: Go to "ati.com" and you get redirected to the regular amd.com front page. Go to desktop graphics products and you get a page titled "AMD Graphics for Desktop PCs" inviting you to shop for "AMD Desktop Graphics Cards".

        The actual cards themselves have as product name "ATI Radeon", but describing an "ATI Radeon" as an "AMD graphics card" is accurate.

        • by Yvan256 (722131)

          I'm not sure it would be wise for AMD to drop a known brand name like ATI.

          • by PitaBred (632671)
            AMD is working on a unification of GPU and CPU. It makes perfect sense to start attaching the AMD name to the GPUs.
          • by Darundal (891860)
            Not right off the bat, but a slow transition from one brand to the other, like what is happening now, can be quite good for them.
    • Re: (Score:3, Informative)

      by raftpeople (844215)
      What possible reason could you have to want to be locked into one GPU vendor?

      The reason is that today CUDA has a headstart and is more mature. Eventually things will probably shift to OpenCL but that takes time and people don't want to sacrifice features today.
    • Re: (Score:3, Informative)

      I've seen feature requests suggesting they are considering it, but at the moment too much information is lost in the PTX->LLVM step to be able to generate CAL or OpenCL.

      • Re:Alternative? (Score:4, Informative)

        by CDeity (467334) on Wednesday December 23, 2009 @05:58PM (#30539802)

        The greatest challenges lie in accommodating arbitrary control flow among threads within a cooperative thread array. NVIDIA GPUs are SIMD multiprocessors, but they include a thread activity stack that enables serialization of threads when they reach diverging branches. Without hardware support, this kind of thing becomes difficult on SIMD processors which is why Ocelot doesn't include support for SSE yet. It is also one of the obstacles for supporting AMD/ATI IL at the moment, though solutions are in order.

        Translation from PTX to LLVM to multicore x86 does not necessarily throw away information concerning the PTX thread hierarchy initially. The first step is to express a PTX kernel using LLVM instructions and intrinsic function calls. This phase is [theoretically] invertible and no information concerning correctness or parallelism is lost.

        To get to multicore from here, a second phase of transformations insert loops around blocks of code within the kernel to implement fine-grain multithreading. This is the part that isn't necessarily invertible or easy to translate back to GPU architectures and is what is referenced in the note you are citing.

        Disclosure: I'm one of the core contributors to the Ocelot project.

    • What possible reason could you have to want to be locked into one GPU vendor?

      Hardware, libraries, and Toolkit.
      Cuda was useable way before anything else
      At the Time Cuda came out AMD was using CTM [wikipedia.org].
      Which is absolutely Painful to use.

    • Re:Alternative? (Score:5, Informative)

      by TheRaven64 (641858) on Wednesday December 23, 2009 @03:50PM (#30538716) Journal

      it lets CUDA code run on x86, but still doesn't do anything for AMD graphics cards

      Actually, it does. It lets CUDA code run on any processor that has an LLVM back end. The open source Radeon drivers have an experimental LLVM back end and use LLVM for optimising shader code.

    • "What possible reason could you have to want to be locked into one GPU vendor?"

      Perhaps because you are sick and tired of GPUs that don't die an early death, and love sitting on the phone and being told that it isn't covered by warranty by HP, Dell, Apple, Sony, and the rest.

                      -Charlie

    • by triso (67491)

      What possible reason could you have to want to be locked into one GPU vendor?

      Only that the other GPU Vendor, AMD/ATI, doesn't have a working Linux driver for 3-d, proprietary or open. In addition there isn't much support for their older cards,

    • Same reason people stick to Flash, superior development tools. But there is a catch - LLVM has been romancing vector support, and I believe clang is used as a opencl frontend, so anything with a llvm backend == supports opencl
  • I wonder how the performance of the open source solution is compared to the proprietary compiler by NVidia. If it's good enough, they might be scared.

    • scared ? they should be happy.

    • Here's a graph performance [gdiamos.net]. The GPU version uses NVIDIA's JIT to generate native instructions for a particular GPU so the GPU results here should be more or less the same as if the program was compiled with NVIDIA's static compiler.
  • Wait wut? (Score:4, Insightful)

    by Icegryphon (715550) on Wednesday December 23, 2009 @02:16PM (#30537808)
    Why would you go from CUDA(Fast Floating-points) to x86(slower Floating-points)?
    Is there support yet for double-precision floating points yet on Nvidia cards?
    This makes as much sense as a Wookiee on the planet Endor.
    Unless the Point is portability but, then why write it in Cuda to begin with?
    • Re:Wait wut? (Score:4, Insightful)

      by tepples (727027) <tepples@[ ]il.com ['gma' in gap]> on Wednesday December 23, 2009 @02:22PM (#30537870) Homepage Journal

      Why would you go from CUDA(Fast Floating-points) to x86(slower Floating-points)?

      For running legacy apps that were developed between the release of CUDA and the release of OpenCL. There aren't many, I'd guess.

      • Re: (Score:3, Interesting)

        For running legacy apps that were developed between the release of CUDA and the release of OpenCL. There aren't many, I'd guess.

        Sounds like there is great potential for a tool that will convert CUDA to OpenCL.

      • by Jesus_666 (702802)
        Or for running science-related apps on computers without a NVIDIA GPU. As far as I can tell, computational science is all about CUDA. Even in courses about GPGPU computing you get brief rundowns á la "CUDA is [15 minute explanation]. Then there's also OpenCL and Sh but nobody uses those" and requirements like "everyone needs to use CUDA. If you don't have a supported NVIDIA GPU please buy one or drop the course" because the lecturer is convinced that teaching anything but CUDA would be a waste of time
    • Re: (Score:1, Interesting)

      by Anonymous Coward

      Suppose you have working CUDA code but your dataset is relatively small, say a block of 1000 floating point numbers. Then the overhead of delegating the work to the GPU isn't necessarily worth the trouble.

      • Re: (Score:3, Informative)

        by beelsebob (529313)

        Which is exactly why you should be using OpenCL, not CUDA – because it lets the OpenCL driver decide whether to run it on the CPU or the GPU.

        • by Trepidity (597)

          It doesn't really, though. OpenCL "decides" based on some very high-level, high-granularity features of devices it can enumerate. In practice, if you want your code to run reasonably well, you know which parts are going to run on the GPU and which on the CPU. OpenCL isn't an auto-parallelization solution, just a set of primitives for parallel programming--- more like an MPI or OpenMP that also supports GPGPU than the old 70s holy grain of auto-parallelizing where the compiler or runtime magically figures ou

    • Re: (Score:3, Insightful)

      by SpinyNorman (33776)

      I can think of a couple of reasons it may be useful on x86 :

      - Better debugging tools
      - Allows CUDA development without buying specialized hardware up-front (a lesson I've learnt - don't buy hardware until the software is ready)

      It's also another option for multi-core programming. If the CUDA API is good, maybe it's an efficient way to develop certain types of parallel apps even if you never intend to use it on a GPU.

    • by Anonymous Coward

      Why would you go from CUDA(Fast Floating-points) to x86(slower Floating-points)?

      Because if you don't have the right hardware, CUDA isn't fast floats. It's a program that doesn't run at all.

  • by gnasher719 (869701) on Wednesday December 23, 2009 @02:20PM (#30537846)
    Seems to be just a front-end for LLVM. And if it is just a front-end for LLVM, then why doesn't it support ATI graphics cards? That would actually make it useful; there is no need for a second CUDA compiler for NVidia cards.
  • by RightSaidFred99 (874576) on Wednesday December 23, 2009 @02:51PM (#30538160)
    NVidia isn't real happy about this. No Christmas cards for those guys! In fact the developers should expect some insipid, obvious, and unfunny cartoons will be drawn about them.
  • Doesn't that mean "not compiled at all"

  • by smcdow (114828) on Wednesday December 23, 2009 @04:49PM (#30539248) Homepage

    A bit off topic, but since I'm seeing posts about OpenCL and portability...

    OpenCL will indeed get you portability between processors, however OpenCL does not make any guarantees about how well that portable code will run. In the end, to get optimum performance you still have to code to the particular architecture on which that your code is going to run. For example, performance on Nvidia chips is extremely sensitive to memory access patterns. You could write OpenCL code that runs very well on Nvidia chips, but runs poorly on a different architecture.

    Not saying that portability isn't a good thing, but a lot of people seem to be thinking that OpenCL will solve all your portability problems. It won't. It only will let code run on multiple architectures. You'll still have to more or less hand optimize to the architecture.

    • Re: (Score:3, Informative)

      Not saying that portability isn't a good thing, but a lot of people seem to be thinking that OpenCL will solve all your portability problems. It won't. It only will let code run on multiple architectures. You'll still have to more or less hand optimize to the architecture.

      Like the argument of assembler vs C, I think as time goes on we will find ourselves with code that can do a better job of optimising the code for a specific processing core, given a block of OpenCL code than the programmer. Sure there will

      • There's only so much an optimizer can do, and it depends on how high-level a language it. With C, for example, the optimizer can't turn three arrays of colour values into an array of structures, which would let it use the vector unit for operations. In a higher-level language, which didn't expose the memory layout to the programmer, this is possible.

        In general, high-level languages have more potential for optimization than low-level ones. In contrast, low-level languages make it easier for the program

    • This is one of the strengths of LLVM. If your hardware performs better with some specific tweaks to the code, then write an optimising pass that makes the appropriate transformations. Then you can keep your back end machine code generator as simple as possible. Even better, write your optimiser in a generic way so anyone else tackling a similar problem can reuse your work. Heck if you're lucky someone else has already done so.
  • Why? (Score:3, Informative)

    by Gregory Diamos (1706444) on Wednesday December 23, 2009 @09:13PM (#30541194)

    So there seem to be several questions as to why people would want to use CUDA when an open standard exists for the same thing (OpenCL).

    Well, honestly, the reason why I wrote this was because when I started, OpenCL did not exist.

    I have heard the following reasons why some people prefer CUDA over OpenCL:

    • The toolchains for OpenCL are still immature. They are getting better, but are not quite as bug-free and high performance as CUDA at this point.
    • CUDA has more desirable features. For example, CUDA supports many C++ features such as templates and classes in device code that are not part of the OpenCL specification.

    Additionally I would like to see a programming model like CUDA or OpenCL replace the most widespread models in industry (threads, openmp, mpi, etc...). CUDA and OpenCL are each examples of Bulk Synchronous Parallel [wikipedia.org] models, which explicitly are designed with the idea that communication latency and core count will increase over time. Although I think that it is a long shot, I would like to see more applications written in these languages so there is a migration path for developers who do not want to write specialized applications for GPUs, but can instead write an application for a CPU that can take advantage of future CPUs with multiple cores, or GPUs with a large degree of fine-grained parallelism.

    Most of the codebase for Ocelot could be re-used for OpenCL. The intermediate representation for each language is very similar, with the main differences being in the runtime.

    Please try to tear down these arguments, it really does help.

  • Q: How do you titilate an ocelot?
    A: Oscillate it's tits a lot.

    I thank you.

"Anyone attempting to generate random numbers by deterministic means is, of course, living in a state of sin." -- John Von Neumann

Working...