Page 1 of 3

Visual Studio - popular, but a painful

Posted: Sun Feb 02, 2014 4:45 pm
by FluffyFreak
Hi guys,

I know there are a few of us who use Visual Studio (Express) almost exclusively for Pioneer development but all of us know it's got a lot of flaws.

Take todays fun-new-thing https://github.com/pioneerspacesim/pioneer/pull/2711 which sees me wondering if it's ok for us to replace std::min and std::max due to VS failing to optimise it very well.

The reason I haven't yet fully profiled to get objective, as opposed to subjective, measurements of the performance difference is simple because I want to get peoples opinions as to whether changes like the ones in that PR are a good idea or not.

Eventually MS might fix VS and improve their compiler, but until then this looks like it might impose a burden on other compilers and the project to support Visual Studios (yeah even VS2013) deficiencies.

What do people (/programmers) think?

Andy

Re: Visual Studio - popular, but a painful

Posted: Sun Feb 02, 2014 5:49 pm
by jpab
I think we have to decide on a case-by-case basis, but I don't have any problem with #2711. It does mean people will have to be careful to use the non-standard functions when writing new code, but I can accept that.

Re: Visual Studio - popular, but a painful

Posted: Sun Feb 02, 2014 6:14 pm
by Luomu
FluffyFreak wrote:What do people (/programmers) think?
Profile it, optimize only the hotspots and leave most of the std::min/max use intact under the assumption it will someday be optimal in VS too.

Re: Visual Studio - popular, but a painful

Posted: Sun Feb 02, 2014 10:55 pm
by Reuse
Luomu wrote:Profile it, optimize only the hotspots and leave most of the std::min/max use intact under the assumption it will someday be optimal in VS too.
I totally agree. As I never had the impression that Pioneer runs too slow, this issue of the VS compiler is not a game braker.

Re: Visual Studio - popular, but a painful

Posted: Mon Feb 03, 2014 9:30 am
by impaktor
Pioneer could run a lot faster on my computer. It is so slow starting so if I need to do a lot of testing I generally do it at work where my computer is faster. Starting it on my home laptop is generally a pain.

What if Visual Studio was open source/free software? What if you could easily extend it to do exactly what you wanted? What if you didn't have to rely on Microsoft to "fix problem X", what if it was heavily in use since the 70s, and what if every conceivable problem with writing code since then had been solved and optimized, by thousands of hackers, due to it being so ridiculously easy to reprogram, extend, and improve, while it still was running! No need to recompile, or dig through millions of lines of source code.

What if that editor already exists? And was free, as in freedom, as well as free beer?

Now I have to ask sensitive readers to avert their eyes from the strong light that is to follow:

Emacs.

(as for gcc, probably not so easy to fix bugs yourselves, but at least you can file bug reports, and don't have to rely on the mercy of Microsoft)

Sorry for the rant, don't take it too seriously ;)

But stuff like this and this just blows my mind.

Re: Visual Studio - popular, but a painful

Posted: Mon Feb 03, 2014 9:50 am
by robn
Lets not start down that path. The fact of the matter is that VS is out there and works for a great many people. Forcing people to re-learn their tools is something that Pioneer tries hard to make you not do. Hell, we wrote an entire model engine just to let people keep using the tools they already know!

If people want to use VS (or any other compiler) and they aren't getting in anyone else's way, then more power to them. If that sometimes means a slightly different implementation of something to support quirks of the platform, that's fine too.

If it does the job (and a couple of profiling runs would be nice) then I'm +1 for an alternate implementation everywhere. I'd rather we were all running the same code as much as possible. I don't see any reason to mix both in the hope that one day they'll work well everywhere when we could get the advantage now. Its not like changing it in the future is hard; its just a quick search and replace away.

Re: Visual Studio - popular, but a painful

Posted: Mon Feb 03, 2014 9:57 am
by FluffyFreak
@impaktor, use Emacs if you like, I don't mind using XCode on Mac or GCC on Linux but this thread is about Visual Studio which people are using, including me.

@robn, in that case I will profile it -I was more worried that making the change just to support "yet-another" Visual Studio deficiency was pushing it.

Re: Visual Studio - popular, but a painful

Posted: Mon Feb 03, 2014 11:40 am
by impaktor
Sorry, I just couldn't help myself when I saw the title of the topic. :)

Re: Visual Studio - popular, but a painful

Posted: Mon Feb 03, 2014 6:18 pm
by lwho
Sorry for being late to the party ;) (locked me out of the forum, by changing the email address, and not receiving the re-activation mail).
impaktor wrote:Emacs.
I would recommend eclipse with emacs key bindings (no kidding, that's what I'm using since switching from emacs). No, just use what you like.
robn wrote:If that sometimes means a slightly different implementation of something to support quirks of the platform, that's fine too.
If only they would support a decent set of C++11 features (*mumbling*), and if only the compiler would run under Wine, so we (Linux users) could test if our code compiles under Windows as well.
FluffyFreak wrote:in that case I will profile it
I can do the same for gcc-4.8 under Linux 64 bit, if you want. Should I just use gprof or is the internal profiling code preferable (and if so, how do I use it)?

And as I said on github, just call them Max and Moritz^H^H^H^H^H^H Min ;) *)

*) If you did not understand the joke, it refers to a famous German humorous story by Wilhelm Busch from the 19th century.

Re: Visual Studio - popular, but a painful

Posted: Mon Feb 03, 2014 6:43 pm
by lwho
Just one little addition: Returning by value and returning by reference still has a little semantic difference:

When returning by value, the type must have an accessible copy constructor (even if the compiler optimizes the copy away, it must still be there), which returning by reference does not require. Though, I don't think this is really a problem. If we really wanted to take a maximum of -say- two RefCounteds, we could still use std::max just for that.