stephenbrooks.orgForumMuon1GeneralMuon1 v4.46 alpha 1
Username: Password:
Page 1 2
Search site:
Subscribe to thread via RSS
Stephen Brooks
2013-03-04 15:52:52
I'm starting to alpha test the new version: please download this package and see what you think.

Changes since v4.45:

- OpenGL speedup for plotting particle textures
- Phase space plots improved
- Adaptive energy colour scale
- Adaptive size of particles
- Power status bug fixed: should now keep running under "unknown" power state (improves WINE compatibility)
- Windowed mode
- New version detection bug ironed out on Muon1 back end
- No longer freezes when on laptop battery and in graphical non-screensaver mode
- Muon1 produces the lattices folder if it's not there
- Fixes for HTTP requests on proxies and redirected wireless networks
- No longer requires separate font.dat and fontsmall.dat files
- [Zerberus] fixed the -txttobin and -bintotxt options. They used to cause a crash when used
- [Zerberus] client will skip over trying to download a samplefile if the name of the lattice ends with _nosample
- [Zerberus] old display.dat format was incompatible, causing miniature font sizes?  (Muon1 now uses human-readable display.txt)
- Made "small" font mode more legible
- [RGTx] a save screen function for the viewresults program
- [K`tetch] possible fix for screen-span mode, though couldn't replicate bug
- [K`tetch] "R" for record now works in 24-bit mode
- [K`tetch] "nan" no longer appears as score for some low-scoring results


There is also a muon1_mingw32.exe compiled using a Windows version of gcc.  This may or may not be faster than the LCC-compiled standard version.  You can benchmark this with Muon1bench available from the main page.
Zerberus
2013-03-04 23:39:27
W00t!  That one will go into a new directory, I guess.

Just a little one to add: Would it be possible for muon1 to clean up obsolete samplefiles, in addition to the lattices?
Stephen Brooks
2013-03-05 12:57:35
It's possible but I'm not completely sure I want to change that behaviour, in case people have put their own custom samplefiles in there or something.
Stephen Brooks
2013-03-05 18:54:03
First possible bug: looks like my version isn't giving the results checksums (so they're not being accepted by the network).  Is this happening to anyone else?  Will investigate...

[edit] New alpha version posted to the site.
Zerberus
2013-03-05 20:59:11
By obsolete I mean samplefiles for lattices which have been deleted.  Maybe renaming them to *.old instead will do so one can run a cleanup batch regularly if desired.
waffleironhead
2013-03-05 22:30:10
The gcc version seems quite a bit slower. 

Quick benches on my athlon2 x4 @ 2.6

muon1_mingw32.exe:
17933,1107.0,234.42
18233,1154.0,229.24
18533,1248.7,234.64
18833,1294.9,229.90
19733,1524.4,233.66

muon1.exe:
29902,308.5,373.00
30202,591.8,658.67
30502,790.6,660.00
31102,1071.0,582.94


Stephen Brooks
2013-03-05 22:52:11
That performance discrepancy seems very odd unless I've messed up the compiler flags for MinGW.  Is the low-performing Muon1 taking 80+% CPU or mainly running single threaded?  Also just double check you're not running two at once or something
waffleironhead
2013-03-05 23:00:33
For both tests I've run one commandline client which spawned 4 threads.  Both are using all 4 cores as the task manager shows 80-90% of cpu time being used.
Hopefully someone else is benching the different versions so we have more data to compare. 
Stephen Brooks
2013-03-06 15:38:19
Found a minor mistake that _alpha2 idenitifies itself as _alpha1 in the results... Waiting for some of these results to show up on the versions plots e.g.

to make sure they're being sent and processed properly
Stephen Brooks
2013-03-06 17:26:13
Another iteration: v4.46 alpha 3 is now available.  The MinGW32 version now targets Pentium 4 architecture with SSE2, hopefully that will work on most modern processors.  I think I've fixed a bug where results weren't getting uploaded properly because of the "_alpha" in the version string!  Also the version identifier is correct (v4.46_alpha3) now, although when you send as .bin format it gets stripped back to [v4.46].
Vvolodymyr
2013-03-07 06:54:34
Hi, I was just wondering if it's possible to run the MinGW32 as command line - I'm running through Wine on linux.  Thanks
Stephen Brooks
2013-03-07 10:56:55
If you rename muon1_mingw32.exe to muon1.exe (and the old muon1.exe to muon1_lcc.exe or something), you can use that executable with muon1_cmdline and similar commands.  Type muon1 -?  at the command line to get switches info.
Vvolodymyr
2013-03-07 10:57:52
OK Great - Thanks, will do that.  CheerZ
GP500
2013-03-07 21:26:54
Stehpen isnt there more to gain with a compile on higher CPU's with sse3 4a and x64 instrucions.

many math-projects score high gains with optimizes for newer CPU's.
waffleironhead
2013-03-08 01:31:06
alpha_3 has been chugging along all day with no problems that i can see.

The mingw32 version is still a lot slower than the muon1 version though.

Single core benchmarks:
ming32:

3633,465.8,155.96
3933,531.2,162.17
4233,554.1,154.37

muon1:
13464,3562.5,275.27
13764,3628.7,273.97
14064,3666.1,270.49
14364,3791.3,273.83
Vvolodymyr
2013-03-08 14:27:39
Hi.  I tried running the MinGW32 from command line (-c) as suggested above, but on both Intel and AMD PCs (both 64-bit Linux, Wine) it drops out with an error right away.
"A serious error occurred... etc etc"
the error log starts with "Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0xf758e98e)"

Although running it in visual mode, works fine - but I just don't want to run it like that, not all the time.

P.S. the regular Muon1.exe (v4.46 alfa 3) is running on both machines for more than a day perfectly fine - with an increase of ~9-10% on Intel (i5-2500) and ~5% on AMD (FX-8150) in performance.
Although the AMD cpu utilization always capped at ~60% (with settings of 8 threads or "auto" and still is (both v4.45 and this alfa test one). 
[Edited by Vvolodymyr at 2013-03-08 14:32:42]
[Edited by Vvolodymyr at 2013-03-08 14:33:54]
Stephen Brooks
2013-03-08 15:48:40
@GP500 - For the alternative build I'm using Dev-C++ 4.9.9.2 (a free compiler system) but it's quite old and only has 32bit support right now.  It uses MinGW32 - I think based on gcc 3.4.2. If you know of a free C++ compiler system that is more capable (e.g. 64bit) for Windows I'd be interested to know about it.

As for performance, most of the relevant stuff for Muon1 is in SSE2, as far as I know.  x64 may even make it slower, since pointers then take up twice the amount of RAM and the program tends to be bottlenecked either by floating-point performance or RAM bandwidth.

Its commandline to the compiler looks like this at the moment:

Compiler: Default compiler
Building Makefile: "C:\sjb39\muon1\Makefile.win"
Executing make clean
rm -f muon1.o muon1_mingw32.exe

g++.exe -c muon1.c -o muon1.o -I"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include" -I"C:/Dev-Cpp/include/c++/3.4.2/backward" -I"C:/Dev-Cpp/include/c++/3.4.2/mingw32" -I"C:/Dev-Cpp/include/c++/3.4.2" -I"C:/Dev-Cpp/include" -I"C:/Program Files/LCC/include" -w -fexpensive-optimizations -O3 -march=pentium4 -msse2

g++.exe muon1.o -o "muon1_mingw32.exe" -L"C:/Dev-Cpp/lib" -lopengl32 -lgdi32 -lws2_32 -s -march=pentium4 -msse2

Execution terminated
Compilation successful


@Vvolodymyr - So the LCC compiled version works OK under Wine in any mode?  I haven't yet worked out how to get line-number trace information out of MinGW32 but given its poor performance I might not bother with it at all!

Is your AMD CPU bulldozer-based?  I heard they have shared floating-point units, one per pair of cores, which might explain the usage only showing just over half.
Vvolodymyr
2013-03-08 16:57:22
Hi, Sorry for lack of clarity, a bit muddled today.

Yes the v4.46a3 Muon1.exe (lcc) works perfectly with yield improvements compared to v4.45 - I always run in command line mode.

the Muon1_Mingw32.exe works fine in visual mode,
But not as command line (through muon1_cmdline.bat) - drops out in error right away (after loading results file).  The error log stars with "Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0xf758e98e)"

Do you want me to email the whole error log?

As for AMD - you're right, the FX-8150 is Bulldozer.  That explains it, Thanks.  and bummer
[Edited by Vvolodymyr at 2013-03-08 17:01:35]
Stephen Brooks
2013-03-08 17:30:30
No need to send the full log, they're usually impossible to use unless I actually compile debugging information into the file to begin with.  It looks like it's dereferencing a NULL pointer though.  And you say it's doing it before any text output at the commandline AND only when Muon1 is given commandline arguments (i.e. "muon1 -c" not just "muon1" ) so it could be something to do with how Wine/Linux is sending it the command strings.  Does "muon1 -?" work?
Vvolodymyr
2013-03-08 18:18:50
Oh ok.
It's doing that after a single first line of text output - about loading results. 
That's the gcc(mingw32) - and yes with command line arguments "muon1 -c".
The "moun1 -?" just starts up the Wine cmd window and immediately quits very very fast without any errors or messages.
I could have fidgeted with Wine settings, but I know nothing of programming or where to look and what to try.
I wonder if same happens on native Windows OS.
Zerberus
2013-03-09 19:58:37
For an alpha version this is already really good, and it seems to be fast already.  From a first look on the graphical parts I witnessed a small graphical bug:
-Framerate and AutoView overlap if you did not select small text

Also, how can I start up windowed mode without setting the framerate to 1/1 in the process?
Stephen Brooks
2013-03-09 21:21:47
I guess when I say "alpha" I actually mean "beta" testing (i.e. public or semi-public), though I suppose I decided to call them "alpha" releases to imply there might be something very wrong with them: for instance not producing checksums or not being able to send.  Once the completely stupid "network" bugs are ironed out, the remainder should be as stable as what I've been testing locally.

I think I made windowed mode automatically select 1/1 frame rate to make it "pretty" and animate smoothly, but I think you're right I shouldn't have combined these two features.  The -g switch selects 1/1 independently.
Zerberus
2013-03-09 22:06:06
At the very end of the first graphical fullscreen run with 4.46apha3:

Faulting application name: muon1.exe, version: 0.0.0.0, time stamp: 0x51377b14
Faulting module name: muon1.exe, version: 0.0.0.0, time stamp: 0x51377b14
Exception code: 0xc0000005
Fault offset: 0x000169a0
Faulting process id: 0x1c38
Faulting application start time: 0x01ce1d0eff9b53d8
Faulting application path: D:\Program Files (x86)\muon_.next\muon1.exe
Faulting module path: D:\Program Files (x86)\muon_.next\muon1.exe
Report Id: e130cf12-8904-11e2-abff-0015172156a0


[Edited by Zerberus at 2013-03-09 22:06:57]
Stephen Brooks
2013-03-09 23:22:44
Next week I'll add a debug build (with the LCC-Win32 compiler) to the alpha3 distribution so you can find out what that is.
Zerberus
2013-03-10 00:20:35
It reproducibly crashes when it wants to write an queuegfx.txt file.

The MinGW32 version doesn't crash, but it is a lot slower.

Edit: MinGW32 seems to crash, too, at least when loaded from autogfx.sav.
[Edited by Zerberus at 2013-03-10 00:32:50]
Zerberus
2013-03-10 10:08:14
Well, let's say it wanted to write files.  As it was the first run ever, it could be queuegfx.txt, results.txt, results.dat...
shauge
2013-03-10 14:23:55
Visual Studio Express should be a modern free C++ compiler
http://en.wikipedia.org/wiki/Microsoft_Visual_Studio_Express

I have not used the express version myself though.  SSE2 instructions are fairly old, it would be very interesting to see how much newer instructions could improve the project throughput, e.g. AVX instructions.  It has given an significant improvement in other projects. 
Stephen Brooks
2013-03-11 16:32:16
If you download the alpha 3 archive again it now contains a "muon1_debug.exe", which is the LCC version with stack trace error box enabled.  In graphical mode, seeing this error box may require some careful use of Alt-Tab to minimise the fullscreen graphics.

If the error is to do with creating new files, have you checked the folder you're using allows everyone write privileges?  (All users not just you)

SHauge - thanks.  I'll bear Visual Studio Express in mind for a later version, though I've not had terribly good experiences with Microsoft compilers in the past (their projects always seem to want to include lots of MS-specific features rather than just compiling code).  I've got a few long plane flights coming up from April, so I might play with different compilers on my laptop!
Zerberus
2013-03-12 10:45:37
Tested it on a different PC with the muon1_debug.exe

First, if I try to switch on the plots (pressing H) I get this:



Even if I set it in display.txt directly, it just crashes again.  The non-debug version works.

[Edited by Zerberus at 2013-03-12 11:00:16]
Zerberus
2013-03-12 11:15:29
A new graphical problem I witnessed.  Or is it intended?


The debug version seems to avoid the crash at the end somehow, at least on this system.

[Edited by Zerberus at 2013-03-12 11:24:33]
Stephen Brooks
2013-03-12 12:39:08
Think I've managed to squash Zerberus's bug (I'd defined an array wrongly in a sorting algorithm that the phase space graphs call) and muon1_debug.exe has been updated in the alpha 3 archives.

See if you can now catch the end-of-simulation bug in the debug build (assuming it wasn't a consequence of the phase space buffer overrun).

The graphics "bug" looks like you've got XYZ reference axes turned on(?) Is there a display option somewhere you can toggle (runtime or display.txt)?

Zerberus
2013-03-12 15:28:51
Yes the second problem was mine.  I had activated the ''show axes'' option without noticing.  Stupid me.

I'll now hunt for the other bug/issue.

Question: Is is possible to display the Mpts ''highscore'' for the lattice the simulation is running currently on?
Zerberus
2013-03-12 15:45:40
Crash at the end of the simulation/beginning of next (since I see the text "Hello, Zerberus" on the screen (not always).  Other times it just hangs.



On a side note, that directory is on Everyone Full Control.


[Edited by Zerberus at 2013-03-12 15:47:10]
Stephen Brooks
2013-03-12 16:20:44
So that's happening at the simulation end.  Interesting: same bit of code.  I looked and found a couple of things that might be causing problems - possibly trying to create/sort an array of zero elements.  Can you download the archive again (muon1_debug.exe should now be timestamped 2013-03-12 16:18) and see if this bug goes?

When you say Mpts "highscore", you mean as some way of estimating the time to complete the result?
Zerberus
2013-03-12 21:15:28
This will be the first thing I'll try tomorrow (have to sleep now, sorry).

Highscore = the highest Mpts for the lattice currently running, as known by your client.
Zerberus
2013-03-13 14:58:41
Couldn't get an error at the end of a simulation anymore.  But to effectively continue testing, I'd need a non-debug build based on the current one.  The debug build is slow as hell. 

Oh, by the way: Is there a way to stop the leaking of particles out of the accelerator?  Particles flying in backward diagonal directions seem to be especially vulnerable to leaking out.
[Edited by Zerberus at 2013-03-13 15:00:15]
Stephen Brooks
2013-03-13 15:27:38
Good, there'll be an _alpha4 build out some time soon now.

Although I've improved the number of leaky particles greatly, I think there's still a way for them to get out near the beginning, especially in early runs where the solenoid is in a strange position.  It's fairly harmless but I'll look into it for a later version.
Stephen Brooks
2013-03-13 16:25:19
[update] There's a new alpha 4 build available from the main page.  Hopefully it's fixed
  • the two crashes
  • Frame-rate and auto view text overlapping
  • -w switch also activating -g (1/1 frame rate)
Slow MinGW32 has been trashed for now.  The muon1_debug.exe is updated to _alpha4 along with the main muon1.exe.

A side effect is that you can now combine the -g "smooth graphics" switch with the -scr screensaver mode too if you want.  Specifying -w and -g gives the old -w behaviour.
Stephen Brooks
2013-03-14 18:25:39
Oops, -g switch still didn't work properly in _alpha4 because it was overridden by display.txt!  Fixed in the development source.
Zerberus
2013-03-15 20:38:21
Since it's looking good so far, I'll try to update my main workhorses to 4.46alpha4.

Does the server take 4.46alpha results already?
[Edited by Zerberus at 2013-03-15 20:39:03]
GP500
2013-03-16 10:46:26
i have a higher mpts rate on the alpha3 then the 445.

I was looking @ the CPU-time and been 10-15% seems to stay on idle time.  46 hrs lost so far, quad BE 955.
That seems allot.
Zerberus
2013-03-17 00:00:14
Minor issue: When displaying size of results database and size of results since last send in graphical modes, fractions following the dot are not correctly shown.

Example: The results database is 84.70 MB, but muon1 only displays 84.00 MB.
[OCAU] badger
2013-03-18 00:50:22
Have been running alpha 3 for five days now, seems to be a bit faster than v445 despite running slower (shorter) simulations due to only 2 lattices (one no sample).
Muon bench:
on i7 2600@ 3401 MHz:
v445
66709,4015316.0,2340.59
v445 (threads set to 50)
512114,19741474.6,2607.51
v446
776674,219999.6,2502.86
v446 (threads set to 50)
878428,483593.6,2621.03

It might be a bit faster now I have some results in results.dat - will rebench with alpha 4.
No crashes or problems so far, but running in commandline mode only.
[OCAU] badger
2013-03-18 01:36:56
Installed alpha4 by copying the new muon1.exe into the directory, when I ran it, it deleted the save file from alpha 3
Stephen Brooks
2013-03-18 12:56:19
GP500 wrote:
I was looking @ the CPU-time and been 10-15% seems to stay on idle time.  46 hrs lost so far, quad BE 955. That seems allot.

Try reducing the "particles per extra thread" to 50, 40 or 25. Does that help?  I'm thinking of changing the default because modern CPUs and OSes seem better at handling short-lived threads.

badger wrote:
Installed alpha4 by copying the new muon1.exe into the directory, when I ran it, it deleted the save file from alpha 3

That's by design.  I might change the autosave format between versions, so it will delete the temporary save file.  Better than a crash or an erroneous result.
Stephen Brooks
2013-03-18 16:52:52
Zerberus: "Does the server take 4.46alpha results already?"

Yes, it's taken them since _alpha3 I think.  The first two alphas didn't put checksums on the results, but that wasn't intentional!

Think I've fixed the decimal place bug in the development source.

Badger's benchmarks suggest I should set the default particles/thread lower limit to 50 or so.  Any more comparisons people can get on this would be good (though benchmarking takes time).
GP500
2013-03-18 18:42:47
I will try that, with a new start and benchmarking, overnight i think.
[OCAU] badger
2013-03-19 00:46:22
Benched for a bit longer with alpha4 and particles set to 40:
1195977,1319881.9,2660.31
1196577,1322003.3,2667.15

also on e8400 @3GHz,
particles 40
336233,423182.8,605.35
particles 70
406387,1582141.5,605.45 (not much difference for particles setting)
(v445 results, particles 25)
1813891,12316044.3,603.51

Have moved my other 2 boxes onto alpha4, see how they go

Stephen Brooks
2013-03-19 11:31:41
So those last 3 on the E8400 are comparable to each other?  (all same version but different particles) Kind of implies the optimum is around 50, as 25 is getting worse, though that's probably within the bounds of error.

I've done some debugging on a Linac900Ext8Xc2 simulation.  This graph plots number of particles vs. time to complete one step.



The simulation cycled between using 1,2,3,4 threads on this 4-core Xeon machine.  (Muon1 detected 4 logical cores although the web says the Xeon E5620 has hyperthreading, that's a bit odd).

Anyway, the graph seems to say that for 0-40 particles I want to pick 1 thread.  2 threads is optimal for 40-60 particles.  3 threads for 60-100 particles and then from 100-150 particles it's not entirely clear whether 3 or 4 are better, but from 150 upwards 4 threads is the clear winner.  Remember the 4 thread mode might be slightly compromised by other things running on my system.

That's consistent with a particles-per-thread setting of somewhere between 33 and 50.
Stephen Brooks
2013-03-19 12:43:28
OK, v4.46 alpha 5 is out, you can download it from the main page. Changes since alpha 4:

  • config.txt option to delete old sample files (warning- default "yes")

  • Default "particles per extra thread" changed from 100 to 35 but remember if you carry over your old config.txt you'll still have 100 in there unless you change it or delete config.txt or do a fresh installation

  • [Zerberus] Max Mpts for the current lattice is displayed on the graphical stats that shows Mpts (press space once)

  • [Zerberus] Decimal places fixed in display of results file size, no longer all zeroes

  • Dot-like particle textures runtime option (press E)

  • Fix to -g switch actually works this time (didn't work before because got overridden by display.txt)


I now wonder what Zerberus meant by the "show highest Mpts" - did you mean in graphics mode or commandline mode or both?  Because I've only done graphics mode at the moment.
: contact : - - -
E-mail: sbstrudel characterstephenbrooks.orgTwitter: stephenjbrooksMastodon: strudel charactersjbstrudel charactermstdn.io

Site has had 17426608 accesses.