Re: OpenMP conclusions

>
>> Overall I recommend reading http://bisqwit.iki.fi/story/howto/openmp/
>> which is a rather good tutorial.
>
> Quickly glanced over it and it looks interesting, will read it later.
>
yes that's the best balance between a tutorial/reference
material/documenting quirks I could find...
>> Once a suitable area for OpenMP is identified, the tricky part is to
>> understand clearly what happens in the code that we are handling. The
>> reason it took me so long to integrate OpenMP was that I hadn't
>> realized that reading an image meant writing it in the cache, and thus
>> the image cache had to be protected. Once that was figured out, adding
>> criticall section around the variable access was easy. Same thing with
>> SDL surfaces that need to be protected because they are ref-counted.
>
> Since threading in general is tricky, I wonder how easy will it be to
> accidently break OMP due to seemingly unrelated changes?
that's a good question, I'm not too worried for the animation part
because it is well contained...
I think OMP will only be used on a few well-contained area and not
everywhere throughout the code, which should help quite a bit.
> Would it make
> sense to document what code is depending on OMP and which preconditions
> it relies upon?
>

Re: OpenMP conclusions

The real trouble with OpenMP and threading ends up being less about the threads and more about whether or not anything is gained.

From experience I've learned to keep a sequentially optimized version and always test against that. Even if all cores are being used in the openMP version there is a chance that bottlenecks slow it down enough to make the sequential no slower.

Re: OpenMP conclusions

On Thu, Mar 3, 2011 at 5:04 PM, Michael Hoffman
<archangel.associate <at> gmail.com> wrote:
> The real trouble with OpenMP and threading ends up being less about the
> threads and more about whether or not anything is gained.
>
> From experience I've learned to keep a sequentially optimized version and
> always test against that. Even if all cores are being used in the openMP
> version there is a chance that bottlenecks slow it down enough to make the
> sequential no slower.
>
fortunately, compiling an openMP code sequentially is trivial (just
remove the compile flags)
The gain also higly depends on the number of cores that are used.
Again it's all in the choice of what areas are to be parallelized.
Calculation intensive areas like AI or loading WML are the most likely
targets
> --
> Michael Hoffman
> ROSE Compiler Group
> Lawrence Livermore National Laboratories
> Department of Energy
>
> _______________________________________________
> Wesnoth-dev mailing list
> Wesnoth-dev <at> gna.org
> https://mail.gna.org/listinfo/wesnoth-dev
>
>

Re: OpenMP conclusions

Yes, but code that would optimally coded to run in parallel may very well not run optimally in sequential, or at least that's what I've seen. Of course if you wrap the existent code in OpenMP then yes, you can make the comparison that way.

On Thu, Mar 3, 2011 at 5:04 PM, Michael Hoffman
<archangel.associate <at> gmail.com> wrote:
> The real trouble with OpenMP and threading ends up being less about the
> threads and more about whether or not anything is gained.
>
> From experience I've learned to keep a sequentially optimized version and
> always test against that. Even if all cores are being used in the openMP
> version there is a chance that bottlenecks slow it down enough to make the
> sequential no slower.
>

fortunately, compiling an openMP code sequentially is trivial (just
remove the compile flags)
The gain also higly depends on the number of cores that are used.

Again it's all in the choice of what areas are to be parallelized.
Calculation intensive areas like AI or loading WML are the most likely
targets

Re: Wesnoth in GSOC 2011

Nils Kneuper <crazy-ivanovic <at> gmx.net>
2011-03-04 22:27:00 GMT

Am 10.02.2011 21:56, schrieb Nils Kneuper:
> Hi everybody!
> As was decided during WESDEM over the last weekend we want to participate again
> in GSOC this year. This basically means that we got some tasks to do:
> 1) Create a nice idea list.
> 2) Find mentors for possible areas/projects.
> 3) Gather the required info for google.
Submissions are open since Monday and will stay open till next Friday. This is
basically a reminder of what needs to be done before stuff can be submitted.
> re '1':
> timotei already prepared the ideas list and cleaned up last years [1]. We do
> have to (re) add the pages that are still valid and also have to add new ideas.
> Please keep in mind that we also have to slightly change the focus since we want
> to put more of an focus onto directly creating "complete" documentation for the
> work done and instead tune down the amount of pure coding required. Please do
> also keep in mind that we came to the conclusion that our projects so far were
> likely "too large", so try to make sure that the ideas are not larger than what
> we had so far.
Is the ideas list [1] already done? At least far enough that I can submit to
google? I know that at least Mordante and Boucman already had a rough look, but
are there "enough" ideas already? Are some of the ideas we had for last year
still usable?
I think that the list currently really sucks and that we have *no* chance to be
accepted with the list in this sad state.
Yeah, submissions are open and I'd prefer to do so over the weekend, deadline is
next Friday and I don't plan to cut it close, but won't submit unless we got at
least "some" ideas that are reasonably well done...
> re '2':
> Volunteers welcome! If you think you have the time to mentor a student, please
> step up possibly also stating which ideas/areas you are most willing to mentor,
> though we have eg seen with the sample boucman gave that "something completely
> different" can work nicely, too.
So far at least Boucman and Mordante clearly stated that they want to mentor,
some others said something along the lines of "yeah, I could mentor..." during
FOSDEM.
> re '3':
> So far we have been able to basically reuse the same info every year. For this
> we were using the stuff listed at [2]. We have to make sure that this list is up
> to date as well as "complete". The latter part is especially important, since it
> sounds like this year the list of questions asked might be changed/extended.
> Carol (the head of GSOC over at google) sent a mail to the mentor mailing list
> stating that they want to see more unknown orgs that might go under the radar
> otherwise participate. So if you know some org that you think could be a
> possible candidate, please talk to them. In the forms we can recommend smaller
> orgs that we think should get a chance, too, and the smaller orgs can list us as
> reference, too. If you can recommend some org to participate please tell them to
> list us as reference (but also make sure to tell the rest about it).
I'll have a look at gathering the latest questions that google requires to be
answered [2] some time tomorrow. Regarding projects that we want to support:
* Is there a list of proposals somewhere?
* So far 'eoc' joined #wesnoth-dev and asked for our support for "unknown
horizons", a strategy game somehow similar to the "Anno" series (rather well
known in Germany, probably not as known outside since it has no shooter elements
;) ).
> I don't know yet how much of the stuff I can work on myself and if I'll be too
> much of a help with things because of this strange thing called real life. So I
> am thankful for anyone working on getting things done. Registration for GSOC as
> project opens at Febuary 28th and lasts till March 11th So until that time we
> got to have the basic stuff together.
> Please do also make sure to gather easy coding tasks [3] and possibly some not
> so easy coding tasks [4] so that students find some things to get started with.
Yeah, I think there are not many easy coding tasks [3] available at the moment.
Do any of those tasks come to your mind and does the list only consist of open
tasks at the moment?
Cheers,
Nils Kneuper aka Ivanovic
[1]http://wiki.wesnoth.org/SummerOfCodeIdeas
[2]http://wiki.wesnoth.org/SoC_Information_for_Google
[3]http://wiki.wesnoth.org/EasyCoding

Re: Wesnoth in GSOC 2011

Nils Kneuper <crazy-ivanovic <at> gmx.net>
2011-03-08 11:41:20 GMT

Okay, so what is the status of the google application? Does someone actually
have the time to look into stuff? Do you think there is enough done yet?
Personally I have the impression that this is not the case and I know that I
don't have the time to improve stuff.
I'd like to submit the application to Google on Wednesday (meaning in about 30
hours) or on Thursday (in 54h) at latest. If stuff is not done by then I guess
that we should spare google the work of looking through our (currently bad!)
application.
I'll wait with submission until I at least get the go ahead from two
volunteering mentors that they think the stuff is good enough and ready for
submission. Either give me this go ahead here on the ML or ping me in IRC (and
make sure that I reply that I have seen it!).
Cheers,
Nils Kneuper aka Ivanovic

Revival of the editor branch

Fabian Mueller <fabianmueller5 <at> gmx.de>
2011-03-10 23:23:49 GMT

Hello,
I am currently working with AI on getting the fendrin_editor branch
polished and in sync with trunk
in order to get it in before the feature freeze for version 1.10.
To avoid further discussion about the map format I have figured out a
way without changing anything of it.
The new features will not affect backwards compatibility in any way.
Changes to the editor's map loading system are minimal inversive.
If a new map format is still wanted (and we can reach an agreement) that
work can be done easily after implementing the rest since
the code is well encapsulated for that.
The editor will not write in scenario files to avoid conflicts with a
human editor.
I still plan to implement the following features:
* Map [label] placement
* Setting the ownership of villages to a side
* Unit placement
* support for [area], a tag naming map locations that can be used
as arguments to SLFs
* placement of [item]
* maybe support for [sound_source]
I am open for more features if they don't cry for a full campaign editor.
The goal is too reduce new features to ones that do benefit from visual
on the fly placement,
so don't suggest support for event coding or something similarly advanced.
I have figured out a gui layout that is still wasting less space than
the game itself,
so there won't be problems on devices with small resolutions.
Cheers,
Fabian Müller alias fendrin

Hello,
I am currently working with AI on getting the fendrin_editor branch polished and in sync with trunk
in order to get it in before the feature freeze for version 1.10.

To avoid further discussion about the map format I have figured out a way without changing anything of it.
The new features will not affect backwards compatibility in any way.
Changes to the editor's map loading system are minimal inversive.
If a new map format is still wanted (and we can reach an agreement) that work can be done easily after implementing the rest since
the code is well encapsulated for that.

The editor will not write in scenario files to avoid conflicts with a human editor.

I still plan to implement the following features:
* Map [label] placement
* Setting the ownership of villages to a side
* Unit placement
* support for [area], a tag naming map locations that can be used as arguments to SLFs
* placement of [item]
* maybe support for [sound_source]

I am open for more features if they don't cry for a full campaign editor.
The goal is too reduce new features to ones that do benefit from visual on the fly placement,
so don't suggest support for event coding or something similarly advanced.

I have figured out a gui layout that is still wasting less space than the game itself,
so there won't be problems on devices with small resolutions.

Re: Revival of the editor branch

Mark de Wever <koraq <at> xs4all.nl>
2011-03-13 10:12:38 GMT

On Fri, Mar 11, 2011 at 12:23:49AM +0100, Fabian Mueller wrote:
> To avoid further discussion about the map format I have figured out
> a way without changing anything of it.
> The new features will not affect backwards compatibility in any way.
Good to hear that.
> Changes to the editor's map loading system are minimal inversive.
> If a new map format is still wanted (and we can reach an agreement)
> that work can be done easily after implementing the rest since
> the code is well encapsulated for that.
>
> The editor will not write in scenario files to avoid conflicts with
> a human editor.
Nice, since it's not going to be a scenario editor the file needs to be
human editable. And in my experience tools that write files and need to
be hand edited afterwards are often no fun at all, most of the time
ending in being completely hand written.
> I still plan to implement the following features:
> * Map [label] placement
> * Setting the ownership of villages to a side
> * Unit placement
> * support for [area], a tag naming map locations that can be
> used as arguments to SLFs
> * placement of [item]
> * maybe support for [sound_source]
>
> I am open for more features if they don't cry for a full campaign
> editor. The goal is too reduce new features to ones that do benefit
> from visual on the fly placement, so don't suggest support for event
> coding or something similarly advanced.
That has always been my fear regarding changing the editor, that at some
point it gets hard to edit maps and not able to do full campaigns,
turning it into a jack of all trades, master of none. However the
features you propose seem to be reasonable.
> I have figured out a gui layout that is still wasting less space than
> the game itself, so there won't be problems on devices with small
> resolutions.
Well I think the gui of the editor can really use a facelift, but I've
no real suggestions how to make it look better. But I think doing the
facelift and adding the features at the same time will make it possible
to make sure it's usable as both a map editor and as a visual scenario
placement tool.
--
--
Regards,
Mark de Wever aka Mordante/SkeletonCrew