Switching to Linux: A Windows developer’s view
A few weeks ago, I switched my development environment from Windows to Linux, on a project which was developed so far on Windows only. In this post, I want to describe the issues that brought me to this switch, a short overview how I did the actual port, and some observations on Linux for developers. This is the first post in a series of at least two, the second post will describe the tools I use on Linux right now.
Background
The project I’m working on is written in C++, with some Python tools mixed in. My original development environment was Visual Studio 2005 on Windows XP. This is already the first issue: Updating Visual Studio or Windows is not trivial, as both the OS upgrade as well as IDE updates require new licenses, and especially in companies new versions are not bought immediately.
The problems became apparent when I tried to multi-thread parts of the application. At the core, it’s doing a lot of number crunching, in small work blocks which can be processed independently. As I couldn’t use OpenMP due to dependency issues (a 3rd party library could not be linked when OpenMP was enabled), I was threading manually. Unfortunately, the application had to allocate some memory in each thread, and as it turned out, the scaling on XP was catastrophic. While I did get a speedup from 1->3 cores, it became slower from 3->4 – clearly, I was hitting some issues with either the scheduler or the memory subsystem, as my code didn’t have any I/O in it.
A quick try on Vista showed that the same application ran more than twice as fast, but unfortunately, I couldn’t install my IDE on Vista as well, and developing on Windows XP and testing on Vista was out of question. Again, with a free IDE, the change would have been no problem (and the express editions don’t have x64 support*, nor OpenMP, more on this later. * See below for an update!).
On the other hand, getting a recent Linux with a recent compiler was not a problem. With Wubi, Linux can run side-by-side with Windows while giving you a full Linux based development environment. Running side-by-side is especially important when you’re in a corporate environment, as you usually cannot simply erase the disk and install Linux without making the IT angry.
Linux
I used Wubi, with the Kubuntu flavour, as I like the KDE environment a bit more than GNOME – especially as I use Qt for UI development now. Specifically, I used Kubuntu 9.04 x64, while I used a x86 Windows XP previously.
Porting
I started by checking out the code from SVN, so no problems here. Even though the application was written in standard C++ and didn’t depended on Windows-specific functionality, it was built using Visual Studio project files and used a few WinAPI calls. As a first step, I ported everything to CMake – something I could/should have done on Windows already. With CMake, I was able to quickly convert one project after the other, and immediately check for compile errors. This proved to be the best way, as I never came into the situation where I would get huge amounts of compile & linker errors at the same time; I had that when I moved an already CMake based project from Windows to Linux and tried to get it running in its entirety. During porting it’s best to port on subproject at a time, even if the project is originally using a portable build system.
As I mentioned, I used explicit threading on Windows, which I replaced by OpenMP on Linux. Now I could also throw out all configuration stuff for threading; among other things, I wouldn’t have to reduce the priority of my application on start-up – this was necessary on XP, as the machine would become unresponsive during processing otherwise. Boost.Threads might have been a valuable alternative here, but OpenMP is well suited to the kind of loop-parallelism I had in my code, and even simplified it compared to the explicit splitting/execution I used previously.
For graphics, I was already using OpenGL. As I could easily get the nVidia binary drivers running, I had no trouble on this side. Overall, it took me half a day to port, including the time to set up the Linux installation.
Results and some thoughts
The net result is interesting: The same application is running 5-10x faster now when using all four cores, so porting to Linux was really worth the hassle. I assume that with Visual Studio 2010, running on Windows 7, I would get similar performance, but the key point to take with you here is: Getting your stuff to work on Linux only costs you time, and not too much if you are a bit careful. Using CMake on Windows (or another portable build system), writing more or less clean C++ and using portable libraries makes porting to Linux easy, and the switch itself is not too complicated. At the moment, the tooling on Linux is reasonably comfortable (more on this in the next post), and the “pain factor” to switch from Visual Studio to for instance KDevelop or Eclipse CDT is no longer there.
Actually, the switch is so simple that Microsoft should get concerned. For instance, I have been developing mainly on Windows since several years, and I occasionally tried Linux, but I never did a complete switch due to various smaller and bigger problems. However, since 1-2 years, the Linux desktop, together with the tools, is good enough to provide some real benefit, especially if you cannot access the latest Microsoft products. Microsoft used to have the best developer tools by far, and quite stable APIs, which were in my opinions the corner stones of their success. However, they’re changing APIs now rather quickly (WinForms? WPF? WinAPI?), they provide new platforms which require rewriting your applications (I’m still waiting for an application like AutoCAD which has a C# UI and a C++ backend), and the tool release cycle is simply too long – waiting 2 years to get a compiler bug fixed is just ridiculous.
On the other hand, developing on Linux means you have an extremely stable API (POSIX isn’t going to be replaced with PoseFX, for instance), the UI side is rather clear (GTK or Qt, you choose), and the tools are getting better as well (GCC and LLVM are getting better quickly, and installing a new GCC does not require buying a new license). If Microsoft does not turn around the ship with Visual Studio 2010 and some clear statements on the APIs, I assume that more and more developers will find that Linux can be also a very nice environment. Again, more on this next time!
[Update] A few notes, as this article is getting a lot of attention and there are some misunderstandings. Regarding the library, I had access to the source, and I could have built it on Windows — it’s simply very time-consuming, as it depends on many libraries like zlib, which I would have to compile with the new settings on Windows as well. Getting these dependencies on Linux is obviously much easier.
OpenMP vs. manual threading: This did not improve the performance compared to the manual threading, but it was a nice bonus as it cleaned up the code a bit. On Windows, I could not use OpenMP due to link issues. The other bonus came from the switch from x86 to x64. Finally, the Linux memory allocator is much better in multithreaded environments, and this was the biggest performance improvement. In total, the application runs several times faster now, without changes on my side.
Summary: In this particular case, the switch to Linux took me just a few hours, while the benefit for me was rather big: Improved performance, and less hassle with dependencies. The drawbacks — getting used to Linux, different tools — are out weighted by the advantages for me; and that’s the main point of this blog post. I was surprised how easy it was to switch from Windows to Linux completely on this project; as I expected a lot of problems (like for instance, not being able to get the stuff running at all!)
Things might have been different if the library and the dependencies would be easier to build on Windows, and I would have gotten access to a new Windows version/new compiler version, but this is simply how things turned out, and I don’t miss my Windows setup at work.
[Update] The x64 editions of Visual C++ Express require some setup to support x64, but it is possible to add x64 support manually using the compilers from the Windows SDK. Check out the official C++ Express feature list and a guide how to enable x64.
Related posts:
“I disagree wholeheartedly with your assessment. Either the whole thing was dishonest, or you didn’t take the appropriate time to know what your options were, and you’re completely whitewashing the current state of Linux C++ development.”
Agreed. Furthermore, if your poor employer can’t afford the newest Standard or Pro version of Visual Studio ($300 to $500), you can use the Express version for free and do pretty much everything that you need to. I highly doubt that’s the case though.
@DaveK
Please submit a bug report to the Eclipse project.
my co-worker runs a virtual LAMP stack with the sites folder being shared via samba..and edits/tests from windows. it’s kinda cool
@Eric Lawless
No, I’m not a Linux developer who used sometimes Windows — I develop(ed) with Visual Studio 6.0 – 2008.
I looked into TBB, yes — what’s the point however? The 3rd party lib is in-house, and distributed as precompiled binaries for Windows, while you have to compile it on Linux, and building on Windows is simply very time consuming due to lots of dependencies (which you have to build manually as well).
I wrote this blog post because I found it very easy to switch my project at work from a Windows stack to Linux; no more, no less, and the result (more performance, less code) was worth the pain (porting time, getting to grips with Linux). The same might be true for other developers as well. I don’t say that Linux is the best development environment, but it’s not that bad compared to Windows as you try to put it.
@Anteru that doesn’t make any sense. The 3rd party lib could not be linked when OpenMP was enabled on windows. So why does it work on linux?
Cause it was linked with /MT on Windows (statically linked against CRT), which does not work in concert with OpenMP … I would have to recompile, but also rebuild all dependencies as /MT — high pain factor. OTOH, on Linux, I could fetch the dependencies with my package manager, and rebuilding was rather easy.
http://meneame.net/story/pasando-windows-linux…desde-punto-vista-programador-eng ->> http://anteru.net/2009/09/14/604/
@WayneB
Wow, not only is your display pic a windows logo (showing that you probably work for Microsoft), but your comment had absolutely NO arguments what-so-ever to back up your statements. You simply said “your employer should be able to afford our tools” when the fact is that there is no reason to pay for something that is not only not needed, but inferior to what the poster has found for FREE. Why pay for a Cougar when you can get a Ferarri for free…?
@Rick
I’ve heard that argument before, I could pay $349 for a license for a plugin for a lacking development environment to bring it up to parity with a FREE development environment, but I don’t really see that as a strong counterpoint to my observation that VS is lacking compared to free IDEs.
As for the C# vs Java flamebait, I’ve worked in both languages and they are so similar that I don’t really know how you could put one above the other.
@Xarxnd
That was my question too — your non-OpenMP thirdparty library issue doesn’t just magically go away on Linux. If the third party supplies an OpenMP version for linux, why don’t they supply it on Windows? And if you had to recompile it yourself on Linux, why couldn’t you do that on Windows?
I’m not saying Windows developing is great, but your central issue here seems to be a moot point.
Well I always thought Visual Studios was the biggest ripoff when it comes to developing for Windows. This is because, when you look at the other operating systems, you would have Anjuta for Linux+GTK, KDevelop for Linux+QT, and of course, Xcode for Mac OS X, and all of those listed are free.
Of course, the argument is that Visual Studios is just so easy to develop with, and that you can make more money developing with Visual Studios because more than 90% of computer users use Windows. Ignoring Linux for now, the commercial OS known as Mac OS X has a free development tool that is not only free, but on equal grounds with Visual Studios when it comes to usability.
Of course, there are alternative Development Suites when it comes to Windows development, but the de-facto standard for development on Windows has been, and will remain Visual Studios.
“writing more or less clean C++”
funny.
Very nice, welcome to the club
The more developers we have on Linux the bigger chance is some of them will start making more apps for linux, not just windows.
Good luck!
One thing i find really funny is that u decided to switch to linux with out even checking out any of the free IDE’s that are out in the market. Last time i checked i could get eclipse to install just fine on my windows 7 box. So i see this as a little biased since you didn’t even try any open source tools that are available on windows, but thats me. I would never switch to linux if i could do what needed to be done with a windows version of eclipse.
@Bill
“One thing i find really funny is that u decided to switch to linux with out even checking out any of the free IDE’s that are out in the market.”
The point was not to just try some new/different IDE, but to get improvements in performance in compiling, running, developing the code.
Perhaps reading the article properly would help, rather than jumping to Windoze-biased conclusions.
@Laseray
I did read it. He tried only one thing and that was Visual studio 2005. With what that IDE had to offer. He quickly jumped to linux and what ever IDE he decided. He could of done what he did on linux on windows with eclipse. I’m just saying that he could of done what he did with same libraries and with eclipse. Last time i check eclipse does not use the same compiler as VS 2005.
@Bill
No, you didn’t read properly. Anyway, the point was that the OS/compiler combination was dated, switching to Eclipse with GCC on Windows would have given me a new compiler, but my multithreaded performance wouldn’t improve until I would switch to a new OS. The point is, the switch to Linux helped in both that I had less trouble with dependency handling (and OpenMP), and I got better performance, and the cost was just the time it took to port (didn’t have to apply for new licenses etc.)
Have you seen this home-grown stuff? On Windows, you need to get a bunch of dependencies (png, zlib, 3ds, etc.), compile them all and create that library, something which requires a lot of time if you want to change compiler settings (and some of the dependencies were also difficult to compile on Windows, as they would require cygwin). On the other hand, the stuff is easy to get on Linux, and that particular library had Linux support as well; getting the dependencies was much easier.
As I said, I could have recompiled on Windows, but I would have spent one-two days to make sure that I used the right settings on all dependencies etc. — high pain factor.
I’ve been a Linux user since 2000, and never did install Windows on my home computer after NT 5.0, so, I’m lacking some clues on windows there… please pardon me.
As you already know, lots of these dependencies are already installed or at least easily found on most modern Linux distros. For example, If I’m lacking some SDL libs, I can just apt-get them, and bingo.
My question is:
Do you think it would be difficult to port those dependencies as precompiled packages on any Windows platform? (Say, 2000, XP, Vista, and 7), just as easily as it is with Linux now?
Thanks for the great article.
Everyone is also invited to answer
@AntX
Well, these dependencies are often available as precompiled binaries on Windows, but the problem is that there is no “system compiler” on Windows, and hence you would have to provide lots of variations of these libraries (see for instance the Boost installer for Windows.) Ideally, all of those dependencies would have a CMake project in them, this would have solved all issues I had. On Linux, I just grab the system libraries and I can be sure that they work with the default GCC, while this is not true on Windows.
Have you tried to use Netbeans for IDE?
I also have shifted to Linux from development on Windows. Wrote some thing about it. http://www.pakzilla.com/2009/07/02/switching-platform-from-windows-to-linux-for-java-development-what-you-will-miss/
@Anteru
Waiting for it, also wanting to take that step but have yet to grasp what development I should gho for (coming from a Visual Studio environment.)
This seems to be a bit of a lame comparison because there are several apples-to-oranges types of comparison going on.
In the article you called it a “3rd party library”, but in the comments you said it was developed in house and you have access to the source. You’re argument that recompiling it in Windows would have been too much work, but I see no reason why it wouldn’t have been the same amount of work, if not less, as that required to get it compiled in Linux.
Also, did you ever do any profiling? How can you be sure that the bottlenecks weren’t in the “3rd party library” and that they would be resolved by recompiling in Windows and rewriting the threading model like you did in Linux.
I agree that Windows lock-in is annoying at times, but it just seems that most of your claims about improved performance just aren’t backed up by the dramatic changes that came from all the rework you did on the code in Linux.
@Dave Johansen
Having access to the source doesn’t mean I want to recompile the library and all of its dependencies on Windows; in my case, this was more work than getting it work on Linux. The whole switch to Linux took me half a day for this project, including the Linux installation itself. And yes, being in-house can still mean that some other developer is responsible for it, and that you cannot simply go in and change stuff — making it a 3rd party library with respect to my code (as I’m only a consumer of it.) Look for instance at libraries like OpenEXR, compiling it from source on Windows takes a lot of time if you can’t use the precompiled binaries, as it depends on many other stuff which you have to get first — much longer than getting it from the package manager, which is guaranteed to work with your system compiler.
I did profiling, the bottlenecks where in my code only. I didn’t say that recompiling the library did help. What helped was the better default memory allocator in Linux, as well as the fact that I could switch from x86 to x64, and use a modern compiler.
As I noted in the text, I’m pretty sure that a Windows 7 installation with VS 2008/2010 would perform similar; it’s just that testing this was not possible, but testing on Linux was.