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:
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.
Pingback: /dev/ecc » Twitter Tweets about linux as of 16. September 2009 | trashnstuff
Pingback: Jan Wildeboer (jwildeboer) 's status on Wednesday, 16-Sep-09 06:40:16 UTC - Identi.ca
Pingback: Jan Wildeboer (jwildeboer) 's status on Wednesday, 16-Sep-09 06:42:59 UTC - Identi.ca
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.
Pingback: Switching to Linux: A Windows Developer’s View « technichristian.net
I’m not a programmer, although I have taken some classes and done some programs, long ago and far away, as I’m sure you’ll know when I say “fortran” and “pascal”. What I am is a _user_. I am one of those people who enjoys the fruits of what you developers do. And I appreciate it.
Linux has been my environment of choice since Win95 crapped out on me (actually, it was my fault, a sad tale and long), and I was interested to see what your impressions were. I’m glad that the flexibility, speed and quality that I have found as a user are reflected in the development tools as well.
As a user I had also become quickly tired of “license this” and “license that” to try to get anything done.
It’s amusing to see the same outraged voices come out declaring how you must be wrong, or confused, or you just didn’t use the right tools, simply because F/OSS worked better for you than proprietary software. I see it all the time as a user, especially if I dare mention Linux as a possible answer to problems someone is having that seem clear to me to be caused by the sucking maw that is Windows.
Good coding,
Bob-
> especially if I dare mention Linux as a possible answer
> to problems someone is having that seem clear to me to be
> caused by the sucking maw that is Windows.
Absolutely; I see this constantly but users are trained by MS to fear their computer because things break too easily in Windows. Windows users sometimes have an understanding on how to fix these issues, but they think these issues will still be present on Linux without knowing how to fix them.
Yes, KDE is a great platform and UI.
Bloody ell – ten oclock at night and you just inspired me to stick Ubuntu on an old laptop and start messing around.
Pingback: Roy Schestowitz (schestowitz) 's status on Wednesday, 16-Sep-09 21:32:20 UTC - Identi.ca
Nice article. Looking forward to reading the next one.
I have developed software that must to run on both linux and windows. Its written in C++ and builds 3D models from data like that from scanners; it can be quite compute intensive (minutes). I demonstrated that the “same” software running on the same PC using RedHat Linux 5.2 was 3-40 times faster than running using windows XP. What was the cause for this difference? (Obviously, a loop calculating the squares of integers from 0 to N will take the same amount of time on the 2 systems!) It aapeared that the time difference was in memory management — allocating and deallocating large blocks of memory as various operations were applied to the data. My XP system was constantly deallocating/allocating memory while the linux box waited a bit before deallocating memory, especially when lots of memory in RAM was available.
BTW, valgrind is TREMENDOUS for finding c/C++ memory problems. IMHO, its much better than any of the expensive windows equivalents.
The point several people seem to miss is that each dependency in Windows is compiled with different compilers with different options and optimizations. In GNU/Linux you have distro (distribution) dependent repositories, where most things are compiled with GCC using the same options and optimizations.
So, in Linux you wouldn’t need to recompile several things simply because they are already compiled like you need.
Just curious. Since you’ve chosen QT for your GUI and KDevelop for your IDE, have you considered porting your project to other platforms for which these tools are now available? Assuming you’re happy (enough) with the toolset, I’m thinking that the bigger advantage to developing in this environment for most people would be the potential for producing portable applications. That won’t speed up the XP memory allocator for you, but I’d still be interested in your thoughts on the subject.
@Billy Fish
subsytem, not subsysten
Ubuntu, not Ubunto
I’m nowadays developing on Qtt everything that’s possible with it (UI, threads, sockets, files, XML…). It’s just so well designed!
@Zzxxccvv
Qtt? I meant Qt4 of course
I’ve been trying to shift to Linux for development so after initially shifting from Microsoft .NET development to PHP development, I was all settled in Linux till I was assigned to yet another Microsoft .NET project. Although the Mono framework does make a substantial part of the Microsoft .NET Framework available to Linux developers, it just doesn’t go all the way. For example, you can’t create Windows services on Linux and not all of your code works right out of the box.
I really would like to make the switch to something that works across multiple platforms, instead of something that keeps me glued to just one operating system.
Pingback: Arun SAG (sagarun) 's status on Thursday, 17-Sep-09 13:40:10 UTC - Identi.ca