stephenbrooks.orgForumMuon1GeneralNow that there is a Linux client, is there an OS X port in the works?
Username: Password:
Search site:
Subscribe to thread via RSS
Jet from ARS
2002-10-02 03:53:47
Just curious.  I'm not volunteering, as I can't even write 'hello world!' in basic razz . I've got one little Maccie just waiting to jump in.....

Jet from Ars
[ARS]odessit
2002-10-02 04:40:49
Jet, Hello smile
the OSX client is not in the works yet, but the bulk of the work is done in Linux client, so the OSX client may need only very little, if any change in code.  As far as timeframe - confused

Intel P3-M 866 MHz
Duron 1000 MHz
XP 1600+ @ 2000+
Jet from ARS
2002-10-03 02:46:55
Hi, Odessit!

Are you saying it something someone's gonna do, or something someone could do?

Jet, clarifying
[ARS]odessit
2002-10-03 13:38:27
I "think" someone could do, since it is Unix based.

Intel P3-M 866 MHz
Duron 1000 MHz
XP 1600+ @ 2000+
Jet from ARS
2002-10-04 05:46:33
How do you propose we locate a volunteer?

Jet
Tom King
2002-10-06 05:14:01
Offer a reward.
alpha
2002-10-06 10:07:08
A FreeBSD client would be nice.  Unfortunately I don't know enough C to port it.  I doubt it would require much work, any takers?
huraxprax
2002-10-06 14:50:01
on porting:

Now since Ronny has done the hard work, getting it to run on other Unix systems should not be hard.
I tried to run it on an IBM RS/6000 running AIX.  It hase a PowerPC like Macs, so Hardware and endian issiues should be the same.
I just had to change the names of some libraries, and changed snprintf to sprintf in main.cpp since snprintf is not available on AIX 4.2. I had one random result finished, on the second run it crashed with a segmentation fault.  I believe this was caused by a buffer overflow by sprintf.

But i would like to test the results so that i know that there are no errors altering the results.
In the client there is the feature TrialType=SetFromFile, it loads the parameters from a result file but the final results (both score and # of particles are different, i had 7% on a medium result.  So there is still some random involved after loading the parameters, is there some way to bypass this and produce reproducable results?

alpha: have you tried to compile the current sources on FreeBSD?  You need gcc and g++ 2.95, and GNU make then it could compile.  From what I've heard (I don't have FreeBSD anymore) it is rather similar to Linux, while AIX has a reputation of beinge weird and uncomfortable to program.
[ARS]odessit
2002-10-06 16:16:13
Actually if I am not mistaking - BSD will run Linux binary without any recompilation since the emulation is built in or the binaries are compatible or some reason like that.  OSX is a different story.

Intel P3-M 866 MHz
Duron 1000 MHz
XP 1600+ @ 2000+
[Muon.FG]7F4
2002-10-06 16:17:54
>So there is still some random involved after loading the parameters, is there some
>way to bypass this and produce reproducable results?

yes indeed, uncommend the randomgenerator initialization in main.cpp :
srand(GetTickCount())
(and use only one thread)

then you should always get the same random-numbers -> same results
huraxprax
2002-10-07 05:06:17
Ronny, thanks, this works and gives identical results...
...but only on a single system sice it depends on the algorithm of the random generator, I think it is in the libc.  It's different between Linux and AIX, I guess Windows and others bust be yet different and produce other results.  (btw, what is the analogon to libc in the Windows world?)
I guess we have to live with the variancy.  Since a bad design ith 0.x yield won't give 3.x in a different run and otherwise, supposedly it doesn't matter that much.
cu, Benno
[Muon.FG]7F4
2002-10-07 11:38:13
Hi benno

I think you are right, the different results while using more than one thread depends whether the libc uses a random generator for each thread or not.

To prevent this you can create your own random generator:

unsigned int randvalue = 0;

unsigned int getRandom() { return randvalue=randvalue*1103515245 + 54321; };
for every thread (...) and replace all rand() calls, but I guess this is too much work, so when it works with one thread it also works with more threads (I guess)
>btw, what is the analogon to libc in the Windows world?

they also have a libc, but about compatibility/ANSI-standard we'll not talk now ...
huraxprax
2002-10-07 14:20:12
Ronny,
I don't know anything about threading, but since last beta was not threaded and I just have a single CPU it can work without threads too?  The performance seems identical.
I supposed that the random sequences were different.
Butt the idea of writing rand new with the modulo arithmetic seems good, I wanted it just to test whether you can trust the results from another version.
cu, Benno
alpha
2002-10-07 15:10:13
huraxprax: I tried compiling the source on FreeBSD, yes.  It fails.

odessit: Yes, I tried the Linux client on an OpenBSD machine with Linux compatibility enabled, and it worked fine.  However, a native FreeBSD version would be nice.  Especially since I refuse to enable Linux compatibility on any of my *BSD machines smile

--
Matt
Stephen Brooks
2002-10-07 17:37:21
About "libc" - The standard library in C on Windows and Linux is stdlib.h (containing the rand() function), with stdio.h handling printf etc. Is this what you meant?
Me@Home
2002-10-27 17:01:52
Any more progress being made on the OS X port?  I have a disconnected iMac which has now been running OGR exclusively for the past ~50 days - I'd rather have it doing Muon.

Me
/Hi all!  I'm back again!  It's amazing - last I checked, I was one of the ~70 people running.  I was also like the 6th person to join.  My, how times have changed.  big grin
: contact : - - -
E-mail: sbstrudel characterstephenbrooks.orgTwitter: stephenjbrooksMastodon: strudel charactersjbstrudel charactermstdn.io RSS feed

Site has had 25163487 accesses.