Ready Reckoner Area
20 Feb 2008 4:11:00 UTC
Topic 193526
(moderation:
Ok ..... thought I'd fire this thread up to gather the wool for RR development/issues - mainly so that I don't lose the plot - and to keep other threads cleaner. :-)
It seems that as RR has some usefulness, and thankfully I've been pleasantly encouraged, I will continue development hopefully along promising lines of potential. So suggestions/comments/problems here please. :-)
Currently there are many versions that reflect an ad-hoc evolutionary path. Each are web retrievable by accessing this domain using :
http://downloads/mikehewson.id.au/readyreckonervXX.html
where 'XX' is the version ( extant are 1 2 3 4 5A 5B 6A 7A 7C 7D ). A graphical approach was introduced at 5 - subsequently I've been keeping the B versions for CIA use .... :-)
The basic overall specification is:
- XHTML/CSS/Javascript
- cross-browser
- cross-platform
- single file download
essentially in order to NOT exclude any users ie. if you can access E@H with a reasonably recent browser you ought to do fine. I feel that given RR is primarily a tool to enable close examination of E@H app version performances, AND since there are many of those platform versions under almost simultaneous development ( well, limited by Bernd's ability to sleep and/or clone himself! ) then this aim should continue to be adhered to.
In the pipe for RR_V8 are presently the following focii :
- re introduce the single task prediction ability
- permit cycle modelling variants
- some page layout issues
- garbage collection performance
- quantitative curve fitting 'goodness' metrics
- option to lump frequency/band data together for analysis and display ( currently organised via app/frequency/sequence )
- addition of further input(s) field(s), say machine/host ID
- a more helpful hardcopy route
- customised reporting ( beyond brief/verbose ), graphical portion included
- save and restore data/analysis sets on local drives
- at least a partial return to a step-wise presentation
well that's the list as I remember for now! :-)
As it stands one can't actually get all of these wishes due to constraints of the Javascript paradigm. What I propose, and thus seek comment upon, is a move to replace Javascript with Java. [ For those who are unfamiliar with the difference it's kindest to say that they were launched at about the same time in history and thus have the first four letters of their names in common ]. This would enable many features ( local disk access say ) not presently enjoyed, better performing and wider ranging graphics abilities, far better quality garbage collection ( with Javascript this problem will only worsen ), and more efficient/easier development ( for myself ) with object oriented stuff.
If so, then two things will be particularly evident:
- it'll take a bit longer for me to spit out RR_V8 ( but might well be worth the wait? )
- users may need to explicitly install the Java Virtual Machine ( some recent J2SE version say ) once on their machine to take advantage of this, if they haven't already got it on deck. All other aspects of the overall specification will remain ( web page etc .... ).
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Ready Reckoner Area
)
Could you possibly include a post that describes what RR is or indented to be?
RE: Could you possibly
)
Fair question! :-) I assume you mean 'intended'.
Short history: Other posters ( Richard Haselgrove, Peter Stoll ) have gradually discovered a cyclic nature to the tasks that the work unit generator emits. That is, some tasks can take quite a different time to execute than others, and this can be as much as 20-30% variation depending upon the sky position chosen for that task ( all else equal ). This has lead to difficulties/confusion regarding the relative performance of different versions of the science application/program that one's computer is running.
Say if some change to program coding, an 'improvement', gives about a 5% shorter runtime. Then unless we are aware of and can account for the fact that the cyclic behaviour described above varies by much more, we won't be able to sensibly comment on any good or bad news in regard to that coding change.
So primarily the idea is to give the developers better feedback on performance 'out in the wild' by a tool ( Ready Reckoner ) that is sensible of the cyclic aspect. So rather than comparing just two tasks performed for instance, a series is observed if available and the more the better.
Hopefully ( assuming we understand the cycle modelling properly ) we may reliably predict what will be the fastest ( trough ) and slowest ( peak ) running times for some machine and application version combination at some frequency - even if that computer never actually executes tasks near those extreme times.
For most E@H users all this is probably unnecessary/uninteresting and quite rightly so, and may ultimately be folly or seemingly pretend cleverness. However it may define some useful aspects of this distributed computing business. Some of us seem to want to at least 'suck it and see' ... :-)
That seems to be the main rough idea so far anyway, there may be other aspects .... :-)
Cheers, Mike.
( edit ) By no means are any or all of the ideas 'mine' - far from it! I volunteered to do some 'code-smithing' .... :-)
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
As for Java vs. Javascript,
)
As for Java vs. Javascript, it would be wonderful if you could do this all in JSP or servlets and not have to depend on Javascript being enabled on the client side. That said, it depends on what your server has the ability to do. If you have your own server, great. However, if you have a hosted server, at least through GoDaddy, you have to pay extra for Java on the server side. PHP might be a good route to go if you are on a hosting account and you don't have Java pre-loaded on your domain, as PHP 5 generally comes with most Linux hosting accounts that I've seen.
Once you get into the realm of Java, Javascript is so much weaker. If you have your own server, you can easily set up Apache and Tomcat, then just run with it. The college that I'm attending developed this whole suite based on Eclipse/Apache/Tomcat. Eclipse is a very nice IDE, though it does have a few oddities (strange compile-time errors that aren't really errors that eventually go away if you fiddle with it long enough). As I think you pointed out, you don't have to worry about malloc() or destroy() and handling memory and pointers like you do in C or C++ (I also assume C#).
As for an example of the "oddities", try figuring out why you have a compile-time error that states that you can't cast an Object to an Object... EH?!?!?!
I fiddled with that by retyping the line, changing import statements, etc, etc, etc... It eventually went away... Don't ask me. I dunno....
Basically, I think a move to Java would be good, provided it is either free to you or you don't care about the cost. As for installing the JVM, most likely anyone visiting the web site will already have the JVM. I'd shoot for version 5. My professor at school is telling us that the difference between 5 and 6 is not all that much, but she's currently waiting for a version 6 SCJP cert exam to come around to see how big of a difference it is. I think she said they give you an extra 45 minutes for the exam, but the percentage to pass was raised up to 65% or so from 59%... To the end user though, I think version 5 is fine. You might could get by with 1.4, but I'd aim for 5...
RE: As for Java vs.
)
Well, I propose to go Java without going any more server-side than simple file retrieval. Fortunately one is not bound to use applets/servlets/whateverlets ...... :-)
I can create a *.java file which the user downloads, like RR currently, and plumps it up to their JVM for execution without any need for further web involvement. This could arise to the user as a stand-alone window ( routine Swing based elements ) separate from the browser in the traditional GUI sense. I could automate both the download and the JVM invocation for that from, say, a simple HTML page. It's possible ( though unlikely ) that the client's Java instance may prompt to obtain specific libraries downloaded before execution. But I don't currently foresee using anything exotic or third party - outside of any recent J2SE distribution. [ Mind you from what I've seen of Java3D it's a pretty neat look ]. You're right that 5 will be quite sufficient and certainly Eclipse is my IDE of choice here, despite it being a tad obtuse on occasions. Sometimes you just have to follow up using the help/hint file, and make the changes purely to settle the compiler down ..... :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
I think I've managed to get
)
I think I've managed to get around the Javascript garbage collection problem. :-)
I'd be much obliged if anyone would like to try with RR_V7E, and see whether there are any significant lags - try any of the data sets that Gary supplies and just keep banging the app_version and frequency buttons. See if it has a progressive slow down ....
[ I've used the XHTML DOM functions of actually deleting and re-creating the div node that the graphics library writes to & it seems to force a round of garbage collection. I think this is a browser issue rather than a pure JS one. ]
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: I'd be much obliged if
)
I think you have wrought a major improvement. I did manage to present it with something it thought about for a few seconds, then gave a crazy-looking waveshape for, but most likely the input was malformed. The wonderful thing was that the next set of data I pasted in gave near-instant response again.
Formerly, once it slowed, all it did was get slower, even if you pasted in tiny little sets of data.
Much obliged.
RE: I'd be much obliged if
)
Well, now I just fired up 7e today not to test it, but to get a quick read on a 4.32 speedup reported by someone else. I entered just five lines, and hit the "Use inputs" button.
The text results area populated essentially instantly, but key text remaining "processing" and the graph did not appear.
After about ten seconds (on my 3 GHz Q6600), a popup I'd never seen from coming from Firefox when running RR appeared, stating :
"a script on this page may be busy, or has stopped responding..."
That was in Firefox. I copied the same 5-line input into Internet Explorer with 7e loaded.
IE behavior was even worse--no visual feedback at all, then I noticed that is was using all of the CPU for one of my four cores, and even racking up some I/O Read activity. Here are the lines, though perhaps there was something malformed that does not appear in this copied text:
839.85, 520, 73008.56
839.85, 519, 89041.75
839.85, 516, 88146.47
839.90, 508, 57697.53
839.90, 507, 59029.83
These lines look legal, so I assume they got the script into a place it was not meant to go, most likely during the graph generation phase (as the text results box looks complete.
The "verbose most" box text reads:
----------------
ANALYSIS RESULTS
----------------
-----------
App Version : NONE
-----------
Frequency : 839.85
Period of task cycle = 144.2
Task sequence number = 516
runtime = 88146
phase = 0.578
principal value = 0.97
Task sequence number = 519
runtime = 89042
phase = 0.599
principal value = 0.952
Task sequence number = 520
runtime = 73009
phase = 0.606
principal value = 0.945
Number of points = 3
Minimum runtime in data = 73008.56
Maximum runtime in data = 89041.75
Estimated peak runtime = -372732
Estimated average runtime = -68923
Estimated trough runtime = 104489
Estimated runtime variance = 1.28
Frequency : 839.9
Period of task cycle = 144.2
Task sequence number = 507
runtime = 59030
phase = 0.516
principal value = 0.999
Task sequence number = 508
runtime = 57698
phase = 0.523
principal value = 0.997
Number of points = 2
Minimum runtime in data = 57697.53
Maximum runtime in data = 59029.83
Estimated peak runtime = -956863
Estimated average runtime = -309340
Estimated trough runtime = 60264
Estimated runtime variance = 1.063
I imagine that negative peak and average runtime estimates are artifacts of noise in the CPU time for two adjacent samples putting the "curvature" estimation into a nonsensical place.
Granted that a sensible answer is not possible in this case, possibly you may find this input interesting.
RE: Well, now I just fired
)
Thank you very much for that Peter. :-)
Your analysis is spot on .... it's the 'close sequence number problem' again. As the points are near ~ trough/bowl ( 512/144 ~ 3.5 cycles ) then any runtimes not indicating an upward going sine will predict a downward going one ( I call this 'wing flap' ). The plotting part of the algorithm will proceed, though very slowly given the scaling that applies. I let it run on IE7 and 10 minutes later I got several cycles of concave downward half sinusoids - but I had to scroll down across ~ 20 screens to see it all! :-)
The pre-least-squares code ( say V6A ) baulks on this data and refuses to estimate. Fortunately I can add a simple test ( ie. toss negative runtime predictions ) to cope. Ah, it's so true : much more code is written for the exceptional paths than the well trodden ones.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: Ah, it's so true :
)
Indeed it is. And it is hard for an end user to guess which behaviors might fruitfully be brought to the programmer's attention. I'm glad I brought it up--I've actually seen the concave down graph from an earlier RR, but that case apparently scaled more readily, so the excess time was not so apparent as here.
I don't think this one calls for an emergency fix or release, but tossing negative runtime predictions sounds like a good idea for future use.
I'm just passing though a
)
I'm just passing though a trough on my Q6600 run, and it's very clear that the 'wiggle minima' on either side of the true trough base can actually be below the 'smoothed minimum' of the trough as a whole. No wonder the curves can be 'concave down' - if your allocated run happens to omit the 'wiggle maxima', it would look very different. Exclude or process (once we have a complete theory of wiggleness), you can't ignore them.