Quote:Original post by Yann L

Quote:Original post by phantom
To quote DICE; "OpenMP; just so say no. Parallelism can't be tacted on, need to be explicit core part"

I disagree. OpenMP is really good for a certain subset of parallel computing problems. If you are doing parallel number crunching with only limited write interaction between batches (raytracing, GI solvers, fluid dynamics, etc), then OpenMP works extremely well and achieves very efficient core usage.

Maybe, but then again in my experiance something like the parrallel for loops from TBB or ConcRT also achieve very efficient core usage as well. In the case of TTB it allows you more control via parameters which allow you to tune how work is spread across cores.

(edit:corrected typo; TTB => TBB)

[Edited by - phantom on June 4, 2010 4:14:15 AM]

Quote:Original post by phresnel
that it still has no support for OpenMP 3.0, and for some reason fails to find omp.h, even though I've enabled OpenMP in the settings.

It does, but it's only included in the pro version (retarded i know).

Quote:

Quote:
To quote DICE; "OpenMP; just so say no. Parallelism can't be tacted on, need to be explicit core part"

I disagree. OpenMP is really good for a certain subset of parallel computing problems. If you are doing parallel number crunching with only limited write interaction between batches (raytracing, GI solvers, fluid dynamics, etc), then OpenMP works extremely well and achieves very efficient core usage.

Then again, in that situation you should probably port everything to OpenCL/CUDA anyway ;)

I agree. OpenMP rocks (although admittedly you get much more mileage out of icc than any other compiler). You can get some pretty decent speed ups fairly easily without much effort. Building a system around the way OpenMP works can produce some fairly impressive performance improvements. The only problem (aside from standard multi-threading problems) you can hit is memory bandwidth problems. In those cases, look at the GPU....

Occasionally cuda isn't the best option though. 1) Intel GPU's on laptops. 2) Integrated graphics units which borrow system ram. 3) Entry level GPU's that emulate some of the core functionality (eg Geometry shaders on an Nvidia ION). In those cases, it doesn't get much better than openMP imho....

[Edited by - RobTheBloke on June 3, 2010 8:17:49 AM]

Quote:Original post by phresnel
0) that it still has no support for OpenMP 3.0, and for some reason fails to find omp.h, even though I've enabled OpenMP in the settings.

Annoying, there is no OpenMP support in the Express versions of MSVC. It's supported in the for pay versions (top version is $11.5k now!).

-Morten-

Quote:Original post by MortenB

Quote:Original post by phresnel
0) that it still has no support for OpenMP 3.0, and for some reason fails to find omp.h, even though I've enabled OpenMP in the settings.

Annoying, there is no OpenMP support in the Express versions of MSVC. It's supported in the for pay versions (top version is $11.5k now!).

-Morten-

OpenMP is only in the pro version of VC2008. It's not included in Express or Standard editions.... (Although OpenMP is available in the standard version of VC2005 AFAIK). The standard version of VC2008 + The Intel Compiler is probably the best bet for commercial dev at the moment (no bad thing imho ;))

Quote:Original post by Washu

He built it wrong. Left _SECURE_SCL on, and a few other flags were omitted as well.
*** Source Snippet Removed ***
I could tweak the times a bit more and end up dropping that last 3 second difference if I cared to. I really can't be bothered though.

Fair enough I guess, although I just hit "standard release mode" button in Visual Studio, which is I assume what everyone else does. Of course, if you could tell me what else I omitted I would very much appreciate it, both so I can fix my own (non-benchmark) code under Visual Studio and also so I can re-run the benchmark.

Quote:Original post by Antheus

Quote:Original post by Steve132
I couldn't get gcc 4.5 to install (god DAMN the mingw project needs some direction. Whoever is running it is absolutely totally unprofessional)

Could you post a link to the bug report you filed regarding this issue. There doesn't seem to be anything similar filed in last couple of days.

I didn't have to. There were several complaints about it in bugs and on the sf.net comments page. My complaint wasn't that it had a bug, my complaint was professionalism. I'm sure the compiler works just fine, but I don't care if installing it is literally impossible. After reading 3 seperate wiki pages describing 3 different methods of installation, I decided the least painful method of installing and unpacking the 15 different packages required for a simple c++ system into a custom and complex directory structure would be to attempt to run the install script provided on the wiki. Doing this required copy-pasting the text, fixing the encoding errors, installing bash and wget from a 3rd party site (the one provided didn't work, even after I installed a SEPERATE tar unpacker, bzip2 extractor, and lzma decoder, which I had to run each one individually 'cause winrar couldn't do it). After an hour or two of work, the script didn't run because all of the package names and locations have been changed on the server, so I just said "forget it." Yeah, maybe somewhere in the wall of 10000 words of conflicting "how to install" text I missed a step, and someone will correct me, but I just don't care. There is a difference between developer documentation and user documentation, and the user experience is absolutely the most important part of any tool. Until mingw-get is released, and actually works, and also has a standalone installer for offline use, the entire 4.5 release is completely impossible for a normal person to actually install, and before the 4.5 release, the same thing was pretty much true for the entire 4.x release.

Quote:Original post by Steve132

I didn't have to. There were several complaints about it in bugs and on the sf.net comments page. My complaint wasn't that it had a bug, my complaint was professionalism.

Hence my comment - do you believe you acted professionaly?

Despite encountering problems, finding inaccurate or inadequate documentation, being unable to get the task done, you apparently did not feel to report any of these issues, nor update existing outstanding reports, nor provided any kind of feedback that would allow anyone in charge to even know there is a problem.

Not knowing about deployment issues is not unprofessional.

It would be unprofessional if you made them aware of the issues in a way that would allow them to resolve it, but it would go unsolved, ignored or neglected for reasons not related to prioritizations, long-term strategy, product life cycle, supported platforms and such.

But downloading a package and getting stuck then whining without even attempting to report, let alone remedy the issue *is* unprofessional.

The software is free. What more could one want. Support however costs money - how about hiring someone to fix these issues?

Quote:Original post by Antheus

Quote:Original post by Steve132

I didn't have to. There were several complaints about it in bugs and on the sf.net comments page. My complaint wasn't that it had a bug, my complaint was professionalism.

Hence my comment - do you believe you acted professionaly?

Despite encountering problems, finding inaccurate or inadequate documentation, being unable to get the task done, you apparently did not feel to report any of these issues, nor update existing outstanding reports, nor provided any kind of feedback that would allow anyone in charge to even know there is a problem.

Not knowing about deployment issues is not unprofessional.
The software is free. What more could one want. Support however costs money - how about hiring someone to fix these issues?

You make a good point that whining about it doesn't fix the problem. So noted. On the other hand, as I already said, there were already several comments on the sourceforge project page explaining and noting the aforementioned deployment issues. Is it professional to re-open and repeat bugs? Although it may have been helpful to be the third or fourth person to point out "Having your users do this massive impossible process is bad," I'm not going to lose any sleep over the fact that I didn't bother to nag him again.

The only reason I elaborated on the difficulties I encountered here was for your benefit, but you make an excellent point that its not nice to simply complain. Fair enough. Next time I can't use an open source project I'll just say "sorry I couldn't do it" and keep the issues to myself.

As for paying someone to fix it, we absolutely agree. If you remember, my original side-comment was "That project needs some direction." Even though I can't afford the money or time required to take over the project and fix it or pay someone else to do so, you and I are in agreement that that approach would be an effective solution to the problems I brought up.

Regardless, this argument seems unfathomably off-topic, and I won't continue it any further.

I'm going to go to work tonight and try to find the flags Washu mentioned, and post the completed benchmark suite then.