The net result of this mess looks like no program can claim to be standards compliant. No one other than M$ will be able to support OOXML due to the incomplete specification and M$ has shown no interest in supporting ODF.
with over 3600 members and 1600+ CPU years of compute time so far.
My team (UserFriendly.Org) is ranked 8'th and expects to overtake SlashdotUsers early next year. http://www.geocenter.com/tempimages/index.html contains graphs for my team, the top 10 teams and WCG overall.
The textured ink / special paper display could be a real help for displaying changing graphical information. Especially if it can be done rapidly - near real time. Carried to an extreme a "tactile CRT" to display things like weather maps, etc. would be very worthwhile.
Another grid computing project is the World Community Grid. Members have contributed over 75,000 CPU years to several projects. See the http://www.worldcommunitygrid.org/.
The last time I checked there were over 260,000 members. Over 100,000 have joined a team. There is a slashdotusers team (one of the larger teams) as well as the one I am in UserFriendly.Org.
Hyperthreading performance depends on how bright the scheduler is as well as the process mix. Last year a cluster vendor asked my company to run benchmarks on their hardware. This was dual CPU Linux boxes. They gave us four to test on. All had hyperthreading turned on.
Our code for the test is CPU bound. Seismic prestack time migration, which may not mean much to most people. We were running two threads per machine. The jobs typically run for hours between I/O operations. The entire process on a large survey can take weeks on a large cluster.
The timing results we got were very inconsistent. In tracking the problem down, I logged into the cluster machines and ran a top. Roughly half of the time the scheduler had both threads running on the same CPU. Turning hyperthreading off increased throughput significantly and gave reproducable run times.
Slashdot Mirror
back in WWII. The patient was an enlisted man who would get falling down drunk after drinking milk. In his case, antibiotics cleared it up.
Robert Gates for President!
I am not sure you can call it justice. The judge didn't recommend he be disbarred.
That might actually help.
See the UserFriendly archive. http://ars.userfriendly.org/cartoons/?id=20070313
I can put my add where you MUST see it!
The net result of this mess looks like no program can claim to be standards compliant. No one other than M$ will be able to support OOXML due to the incomplete specification and M$ has shown no interest in supporting ODF.
with over 3600 members and 1600+ CPU years of compute time so far.
My team (UserFriendly.Org) is ranked 8'th and expects to overtake SlashdotUsers early next year. http://www.geocenter.com/tempimages/index.html contains graphs for my team, the top 10 teams and WCG overall.
The variable velocity is one of the main problems in geophysical data processing. Wave equation migration has been a hot topic for a while now.
The textured ink / special paper display could be a real help for displaying changing graphical information. Especially if it can be done rapidly - near real time. Carried to an extreme a "tactile CRT" to display things like weather maps, etc. would be very worthwhile.
Another grid computing project is the World Community Grid. Members have contributed over 75,000 CPU years to several projects. See the http://www.worldcommunitygrid.org/.
The last time I checked there were over 260,000 members. Over 100,000 have joined a team. There is a slashdotusers team (one of the larger teams) as well as the one I am in UserFriendly.Org.
Hyperthreading performance depends on how bright the scheduler is as well as the process mix. Last year a cluster vendor asked my company to run benchmarks on their hardware. This was dual CPU Linux boxes. They gave us four to test on. All had hyperthreading turned on.
Our code for the test is CPU bound. Seismic prestack time migration, which may not mean much to most people. We were running two threads per machine. The jobs typically run for hours between I/O operations. The entire process on a large survey can take weeks on a large cluster.
The timing results we got were very inconsistent. In tracking the problem down, I logged into the cluster machines and ran a top. Roughly half of the time the scheduler had both threads running on the same CPU. Turning hyperthreading off increased throughput significantly and gave reproducable run times.
We tell our clients to turn hyperthreading off.