Well, I've had the v0.18 source code out there for awhile now, giving people a chance to look it over and do some testing. I'm expecting that when we do update the stock app to v0.18 it should be pretty smooth. Not that many people are running the stock app :P

A while??? That was yesterday when we got the first compilable and testable version. ;)

Anyway, the Linux v18 is out for testing in the Application Code Discussion Forum

Well, the newest version of the code has only been out a day, but I haven't updated the stock app yet now have i? :)

No... but did you have time to look at the results?

So far so good.

---

Thanks Ice, are the ones posted there based on the 0.18 release?

The Windows applications are based on the 0.07 release with the core computational parts transplanted from my modified version of the old 1.22 app (slightly tuned to allow better autovectorization by the compiler) and then some small modifications to get the checkpointing correct and the addition of the required signature string in the output file.

Most likely all I will do is to change the version number to 0.18 because the input and output file formats have not changed and the actual computation is probably also the same. But you don't have to worry about it, there were no new features added since 0.07 (besides the version string in the output).

I must admit that I wasn't sure what version to attribute the optimzed apps to and certainly don't want to get bogged down in version control. I had hoped to keep zslip.com to the latest op apps that were available and returning good results.

I am more than happy to include the Linux/AMD beta versions based on 0.18c, if that is the best way to label them.

---

shenanigans like running test apps in the production environment

I keep mentioning that and Travis shoots it down. Especially after the heck he gave everybody and then made the last opti apps useless, then put out ~10 apps in a week which half never worked. It's always one sided, with some excuse.

...and I keep mentioning that I'm an application developer / programmer and am now training to be a system admin...and that what's being done is what is normally done when a project is ALPHA. The difference is that the general public usually does not see this process. If you didn't know this is typical of what happens, then you're now informed... ;-)

Like I said before, if the changes are an irritant, then you should wait for the project to enter beta testing, which at that point there should be fewer releases.

I know how it goes. I did Nano when it started. But to tell the users to test and not do it yourself is wrong, or not to issue them as 'test' runs. I wonder sometimes how well the staff knows how to write the coding. I think it is rushed sometimes and not double checked, nor tested which leads to mass failures.

The sending of work as "test" tasks seems to me to be quite redundant, since by definition we are testing the software already. They have said that they have limited variations of hardware. If they enable the "test applications" function and a lot of folks don't opt in (it is off by default), then it may make you happy, but do you not see the potential for it taking longer to get a stable application due to people not opting in?

All projects are not for all people...just like all mutual funds are not for all people. There is always the associated risk. If you find that the risk is not acceptable / not manageable, then you should consider something less risky.

shenanigans like running test apps in the production environment

I keep mentioning that and Travis shoots it down. Especially after the heck he gave everybody and then made the last opti apps useless, then put out ~10 apps in a week which half never worked. It's always one sided, with some excuse.

...and I keep mentioning that I'm an application developer / programmer and am now training to be a system admin...and that what's being done is what is normally done when a project is ALPHA. The difference is that the general public usually does not see this process. If you didn't know this is typical of what happens, then you're now informed... ;-)

Like I said before, if the changes are an irritant, then you should wait for the project to enter beta testing, which at that point there should be fewer releases.

I know how it goes. I did Nano when it started. But to tell the users to test and not do it yourself is wrong, or not to issue them as 'test' runs. I wonder sometimes how well the staff knows how to write the coding. I think it is rushed sometimes and not double checked, nor tested which leads to mass failures.

The sending of work as "test" tasks seems to me to be quite redundant, since by definition we are testing the software already. They have said that they have limited variations of hardware. If they enable the "test applications" function and a lot of folks don't opt in (it is off by default), then it may make you happy, but do you not see the potential for it taking longer to get a stable application due to people not opting in?

All projects are not for all people...just like all mutual funds are not for all people. There is always the associated risk. If you find that the risk is not acceptable / not manageable, then you should consider something less risky.

Yes, but sending out thousands of wu's crashing and in turn casing the server to go nuts and crash isn't the best thing to do now is it? So why not run a hundred 'test' ones to make sure the new app runs correctly?

You always assume I am not understanding of anything on this project. As you can see I have been apart of it far longer than you. I've watched how it has gone. From the weeks of no admin appereance to spitting out apps with good times inbetween. With any project there is risks. Nano was shut down because the people funding it had lost interest in that particular area. In the last couple months Rosetta put out a couple bad runs that errored and one where the credit was way under. Maybe instead of talking down to people you should talk at them.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

shenanigans like running test apps in the production environment

I keep mentioning that and Travis shoots it down. Especially after the heck he gave everybody and then made the last opti apps useless, then put out ~10 apps in a week which half never worked. It's always one sided, with some excuse.

...and I keep mentioning that I'm an application developer / programmer and am now training to be a system admin...and that what's being done is what is normally done when a project is ALPHA. The difference is that the general public usually does not see this process. If you didn't know this is typical of what happens, then you're now informed... ;-)

Like I said before, if the changes are an irritant, then you should wait for the project to enter beta testing, which at that point there should be fewer releases.

I know how it goes. I did Nano when it started. But to tell the users to test and not do it yourself is wrong, or not to issue them as 'test' runs. I wonder sometimes how well the staff knows how to write the coding. I think it is rushed sometimes and not double checked, nor tested which leads to mass failures.

The sending of work as "test" tasks seems to me to be quite redundant, since by definition we are testing the software already. They have said that they have limited variations of hardware. If they enable the "test applications" function and a lot of folks don't opt in (it is off by default), then it may make you happy, but do you not see the potential for it taking longer to get a stable application due to people not opting in?

All projects are not for all people...just like all mutual funds are not for all people. There is always the associated risk. If you find that the risk is not acceptable / not manageable, then you should consider something less risky.

Yes, but sending out thousands of wu's crashing and in turn casing the server to go nuts and crash isn't the best thing to do now is it? So why not run a hundred 'test' ones to make sure the new app runs correctly?

You always assume I am not understanding of anything on this project. As you can see I have been apart of it far longer than you. I've watched how it has gone. From the weeks of no admin appereance to spitting out apps with good times inbetween. With any project there is risks. Nano was shut down because the people funding it had lost interest in that particular area. In the last couple months Rosetta put out a couple bad runs that errored and one where the credit was way under. Maybe instead of talking down to people you should talk at them.

Instead of talking "at" someone, it is preferable to talk "to" someone...

No, sending out thousands of crashing tasks is not preferable, but given the fact that they have admitted that they have limited hardware platforms to unit test with, the fact that the optimized applications chew through results very quickly, the fact there there is a very high concentration of Core2 (and newer) systems attached to this project, and the fact that "test applications" is opt-in only, a hundred "test" tasks really won't tell them much more than if they were to go out and purchase a single C2Q system and run one of the optimized applications on it for about 2 hours.

I appreciate your exasperation, but I'd ask you to reflect on all the variables in play...

...the fact that the optimized applications chew through results very quickly, the fact there there is a very high concentration of Core2 (and newer) systems attached to this project, and the fact that "test applications" is opt-in only, a hundred "test" tasks really won't tell them much more than if they were to go out and purchase a single C2Q system and run one of the optimized applications on it for about 2 hours.

I'd like to understand what you are saying here. Are you saying that using optimized apps is no good, that you'd rather I returned a tenth of the WU's (and wasting my computer time and electricity bill when I could be using optimized apps to be more efficient)?

I'm not really sure what the issue is concerning <<"test applications" is opt-in only>>

Nobody ever asked me about this and how am I supposed to know or that it matters? As it happens I have always had my "Run test applications?" to yes for MilkyWay, but I don't recall seeing anyone being encouraged to use this setting.

For those who don't know where this setting is, go to My Account, Resource share and graphics MilkyWay@home preferences,

Run test applications?
This helps us develop applications, but may cause jobs to fail on your computer - yes or no as you prefer.

---

...the fact that the optimized applications chew through results very quickly, the fact there there is a very high concentration of Core2 (and newer) systems attached to this project, and the fact that "test applications" is opt-in only, a hundred "test" tasks really won't tell them much more than if they were to go out and purchase a single C2Q system and run one of the optimized applications on it for about 2 hours.

I'd like to understand what you are saying here. Are you saying that using optimized apps is no good, that you'd rather I returned a tenth of the WU's (and wasting my computer time and electricity bill in doing so when I could be using opt apps to be more efficient)?

No, you are taking the conversation out of context. What I'm talking about is the complaint by Banditwolf that the project should release "a hundred test units" out to everyone before releasing a new search / application. What I am saying is that doing that on a scale that small is of very little practical use. It may provide "feel good" / "public relations" points to some, but it would not be effective. If we wanted to talk about ten thousand test units, then perhaps it would be useful, but then you get into the idea of making a "test run" inside a project that is already supposed to be known to be at a stage where they are testing, which seems quite redundant...

People should understand that this project is not a "production" project. Several people are applying "rules of acceptable conduct" that would be acceptable to be applied to a production-level project to a project that has clearly stated multiple times that they are in alpha test mode. IMO, that's being a bit too demanding...however I have been speaking about this from the perspective that perhaps there is a misunderstanding about the nature of alpha projects and what is needed to be an effective test environment...

...the fact that the optimized applications chew through results very quickly, the fact there there is a very high concentration of Core2 (and newer) systems attached to this project, and the fact that "test applications" is opt-in only, a hundred "test" tasks really won't tell them much more than if they were to go out and purchase a single C2Q system and run one of the optimized applications on it for about 2 hours.

I'd like to understand what you are saying here. Are you saying that using optimized apps is no good, that you'd rather I returned a tenth of the WU's (and wasting my computer time and electricity bill in doing so when I could be using opt apps to be more efficient)?

No, you are taking the conversation out of context. What I'm talking about is the complaint by Banditwolf that the project should release "a hundred test units" out to everyone before releasing a new search / application. What I am saying is that doing that on a scale so small is of very little practical use. It may provide "feel good" / "public relations" points to some, but it would not be effective. If we wanted to talk about ten thousand test units, then perhaps it would be useful, but then you get into the idea of making a "test run" inside a project that is already supposed to be known to be at a stage where they are testing, which seems quite redundant...

People should understand that this project is not a "production" project. Several people are applying "rules of acceptable conduct" from a production-level project to a project that has clearly stated multiple times that they are in alpha test mode. IMO, that's being a bit too demanding...

'Acceptable conduct'?? Gee whiz, beta project or not, I have seen a level of communication here from Travis that I have not witnessed at Seti for years.......at least we know who is turning the knobs, and why he it turning them when things go wrong.........

---

I am the Kittyman.

Please visit and give a Click for Seti City.

...the fact that the optimized applications chew through results very quickly, the fact there there is a very high concentration of Core2 (and newer) systems attached to this project, and the fact that "test applications" is opt-in only, a hundred "test" tasks really won't tell them much more than if they were to go out and purchase a single C2Q system and run one of the optimized applications on it for about 2 hours.

I'd like to understand what you are saying here. Are you saying that using optimized apps is no good, that you'd rather I returned a tenth of the WU's (and wasting my computer time and electricity bill in doing so when I could be using opt apps to be more efficient)?

No, you are taking the conversation out of context. What I'm talking about is the complaint by Banditwolf that the project should release "a hundred test units" out to everyone before releasing a new search / application. What I am saying is that doing that on a scale so small is of very little practical use. It may provide "feel good" / "public relations" points to some, but it would not be effective. If we wanted to talk about ten thousand test units, then perhaps it would be useful, but then you get into the idea of making a "test run" inside a project that is already supposed to be known to be at a stage where they are testing, which seems quite redundant...

People should understand that this project is not a "production" project. Several people are applying "rules of acceptable conduct" from a production-level project to a project that has clearly stated multiple times that they are in alpha test mode. IMO, that's being a bit too demanding...

'Acceptable conduct'?? Gee whiz, beta project or not, I have seen a level of communication here from Travis that I have not witnessed at Seti for years.......at least we know who is turning the knobs, and why he it turning them when things go wrong.........

Agreed, and that's why that while I think the complaint is somewhat valid, it ends up being well on the side of being too demanding.

Again though, perhaps there is a misunderstanding about what the project's responsibility is at this point. At this point, they should do what is called "unit testing" with the hardware that they have available. From there, they are relying on all of us who have signed up to be the testers for the hardware/software combinations that they do not have.

...the fact that the optimized applications chew through results very quickly, the fact there there is a very high concentration of Core2 (and newer) systems attached to this project, and the fact that "test applications" is opt-in only, a hundred "test" tasks really won't tell them much more than if they were to go out and purchase a single C2Q system and run one of the optimized applications on it for about 2 hours.

I'd like to understand what you are saying here. Are you saying that using optimized apps is no good, that you'd rather I returned a tenth of the WU's (and wasting my computer time and electricity bill in doing so when I could be using opt apps to be more efficient)?

No, you are taking the conversation out of context. What I'm talking about is the complaint by Banditwolf that the project should release "a hundred test units" out to everyone before releasing a new search / application. What I am saying is that doing that on a scale so small is of very little practical use. It may provide "feel good" / "public relations" points to some, but it would not be effective. If we wanted to talk about ten thousand test units, then perhaps it would be useful, but then you get into the idea of making a "test run" inside a project that is already supposed to be known to be at a stage where they are testing, which seems quite redundant...

People should understand that this project is not a "production" project. Several people are applying "rules of acceptable conduct" that would be acceptable to be applied to a production-level project to a project that has clearly stated multiple times that they are in alpha test mode. IMO, that's being a bit too demanding...however I have been speaking about this from the perspective that perhaps there is a misunderstanding about the nature of alpha projects and what is needed to be an effective test environment...

Oh, OK thanks, sorry for my misunderstanding. As far as I am concerned, and it's just my opinion, but I think what Travis and Dave have done so far is fine. Crashes and problems are all part of any alpha project such as this, as are volunteers who run PC resource for them who can accept a few knocks; no WUs, lost WUs, etc.

---

...the fact that the optimized applications chew through results very quickly, the fact there there is a very high concentration of Core2 (and newer) systems attached to this project, and the fact that "test applications" is opt-in only, a hundred "test" tasks really won't tell them much more than if they were to go out and purchase a single C2Q system and run one of the optimized applications on it for about 2 hours.

I'd like to understand what you are saying here. Are you saying that using optimized apps is no good, that you'd rather I returned a tenth of the WU's (and wasting my computer time and electricity bill in doing so when I could be using opt apps to be more efficient)?

No, you are taking the conversation out of context. What I'm talking about is the complaint by Banditwolf that the project should release "a hundred test units" out to everyone before releasing a new search / application. What I am saying is that doing that on a scale so small is of very little practical use. It may provide "feel good" / "public relations" points to some, but it would not be effective. If we wanted to talk about ten thousand test units, then perhaps it would be useful, but then you get into the idea of making a "test run" inside a project that is already supposed to be known to be at a stage where they are testing, which seems quite redundant...

People should understand that this project is not a "production" project. Several people are applying "rules of acceptable conduct" from a production-level project to a project that has clearly stated multiple times that they are in alpha test mode. IMO, that's being a bit too demanding...

'Acceptable conduct'?? Gee whiz, beta project or not, I have seen a level of communication here from Travis that I have not witnessed at Seti for years.......at least we know who is turning the knobs, and why he it turning them when things go wrong.........

Agreed, and that's why that while I think the complaint is somewhat valid, it ends up being well on the side of being too demanding.

Again though, perhaps there is a misunderstanding about what the project's responsibility is at this point. At this point, they should do what is called "unit testing" with the hardware that they have available. From there, they are relying on all of us who have signed up to be the testers for the hardware/software combinations that they do not have.

Well.....I for one, will accept the fact that we are all in 'beta' mode.....
Much as Seti has their beta test site......
So, use my rigs for your testing......no problem. I did beta testing for the folks at Lunatics for the opti apps for a long while.....

The only suggestion I might have would be to put a disclaimer on the home page clearly indicating that this project is 'not quite ready for prime time, and disruptions can and will occur'....LOL.

---

I am the Kittyman.

Please visit and give a Click for Seti City.

Well.....I for one, will accept the fact that we are all in 'beta' mode.....
Much as Seti has their beta test site......

We are not at the point of a traditional "beta". I think that's what is also confusing some folks. At Beta, things should be mostly stable. Crashes of the application should be very rare. This project is still classified as "alpha", which means crashes should be expected...

The only suggestion I might have would be to put a disclaimer on the home page clearly indicating that this project is 'not quite ready for prime time, and disruptions can and will occur'....LOL.

Good idea...

Well.....I for one, will accept the fact that we are all in 'beta' mode.....
Much as Seti has their beta test site......

We are not at the point of a traditional "beta". I think that's what is also confusing some folks. At Beta, things should be mostly stable. Crashes of the application should be very rare. This project is still classified as "alpha", which means crashes should be expected...

The only suggestion I might have would be to put a disclaimer on the home page clearly indicating that this project is 'not quite ready for prime time, and disruptions can and will occur'....LOL.

Good idea...

Alpha, eh? Where can I buy stock, so I am in on the ground floor to be a millionaire when it takes off??? My Seti stock took a digger.........

---

I am the Kittyman.

Please visit and give a Click for Seti City.

Now I just with I had some programming knowledge so I could do a optimized app for OS X.

I have 2 machines here on a 9% fix.

Now I just with I had some programming knowledge so I could do a optimized app for OS X.

I have 2 machines here on a 9% fix.

Never did the Mac thingy.......I built all my rigs from scratch since day one.....

Although if I remember correctly, Steve did at one time try to offer the Mac OS for use on PCs....

And I think there are hack sites that make it possible even now.....

---

I am the Kittyman.

Please visit and give a Click for Seti City.

I only have one Mac (T7200-2.0 GHz), the other 2 are a Laptop (Pentium M-1.6 GHz) running Windows 7 and my slim desktop PC (E6650-2.33 GHz) running Vista.

The laptop might soon go back to Linux though.

---

Now I just with I had some programming knowledge so I could do a optimized app for OS X.

I have 2 machines here on a 9% fix.

I've tried a bunch of different optimizations for OS X (because it's what I use personally), and they really don't provide any improvement over what we currently have.

I am using GCC however, so maybe with Intel's compiler we could do a bit better. Unfortunately it's not free so I probably won't be getting it anytime soon :P

---

It looks like Alex Kan was using the Intel compiler to do the Intel builds of his V8 app on SETI.

I don't know what he used for the PPC builds though.

Have you tried the evaluation package, I don't think you can publish the build but it can give you some ideas.

http://www.intel.com/cd/software/products/asmo-na/eng/219690.htm

---

It looks like Alex Kan was using the Intel compiler to do the Intel builds of his V8 app on SETI.

I don't know what he used for the PPC builds though.

Have you tried the evaluation package, I don't think you can publish the build but it can give you some ideas.

http://www.intel.com/cd/software/products/asmo-na/eng/219690.htm

I should be able to get my Mac back within about two weeks, and then I can start on some Mac applications, see if I can speed it up any.

---

I am using GCC however, so maybe with Intel's compiler we could do a bit better. Unfortunately it's not free so I probably won't be getting it anytime soon :P

Strange how college students run torrents... except those who run BOINC projects.

---

me@rescam.org