I've yet to have one last more than two years, and I'd say most don't last more than one.
Really? I've still got bulbs I purchased in around 1992 that are still working. The biggest problem I've had is that they dim as the years march on and get moved to places that require less light.
I have had some last less than a year, but I've found that those are related more to the fixture used than the bulb. Enclosed fixtures especially those with multiple bulbs will reduce the lifetime due to trapped heat. Any fixture where the bulb doesn't fit well and ends up under stress is also a bulb killer.
The biggest problem I have with compact fluorescents is the accumulation of dead bugs in ceiling fixtures. With incandescent bulbs the changes are frequent enough that bugs don't have time to accumulate.
Campbell's thesis is essentially that there is only one story in mythology: "Teenage boy finds finds he is of noble/royal/divine/magic blood and is sent by the gods/elders/wizards on a difficult and dangerous quest to defeat bad guys/rescue hot chick/retrieve magic item/destroy magic item/avenge death of his father."
That would be an OK thesis if it had been left there... Unfortunately it is extended to saying that there is something about this story that is ingrained in our psyche or the "collective unconscious" and that all stories should follow this format because this is obviously what we all want. The antithesis to this is that since we're bombarded with stories of this type from a early age and people gravitate to them because of their familiarity.
It is rarely mentioned that these stories were crafted by people under the rule of a chiefain that considered himself of noble/royal/divine blood. Stories of this type were "popular" for a few related reasons. 1) By glofiying the "noble blood" flowing in the veins of the cheiftain the author earns favor and is less likely to find his head decorating a pike outside the cheiftain's den. 2) The stories serve the purpose of the chieftain by creating fear of the "awsome powers" of the nobility and perpetuating the myth of the "divine right" of those of noble blood to rule.
Personally, I rarely enjoy stories that directly follow this formula. I prefer stories where the hero/heroine denies his/her noble heritage in favor of more egalitarian values and the fight is against the nobility rather than perpetuating it. Either that, or tragedies where the hero's noble blood works to cause his downfall. I hope the ancient "formula" is losing popularity among democratic societies. Some examples indicate this might not be the case, however.
Harry Potter is yet another "chosen one". There's still another book left in which he could renounce magic and obedience to the high wizards then shoot Valdemort in the head with a.45, but I doubt that's going to happen. The Star Wars saga ends with the return of the "noble blooded" priesthood class not to mention planets so under the spell of the nobility that they "elect" ultra rich 15 year old girls as rulers. Was Amidala really suited to rule, or was she the Paris Hilton of Naboo? The house in the lake country would seem to indicate the latter...
I can give you a few reasons they might. Having been through some hardware RAID nightmares I have first hand experience with a few of them.
HW RAID makes you dependent upon the manufacturer of the card both for RAID implementation and for drivers. We once a a couple hardware RAID cards managing a large (at the time) RAID0+1 array that would occasionally glitch and fail a drive or two (or occasionally every drive on the controller). The driver and monitoring daemon wouldn't report anything until a second drive failed. Despite battery backup on the card cache, a single drive failure would often corrupt the data on the mirrored drive. The manufacturer was nowhere to be found when requesting updates or bug fixes.
We eventually switched to software RAID and found that in addition to making the array reliable it improved our performance. This was in part because the 6 CPUs on the machine were significantly faster than the 25MHz i960 managing the RAID cards. We could also mirror across controllers on the 4 separate PCI busses which gets rid of a major bottleneck (the I/O on a PCI bus can be easily saturated by a few drives)).
There are other benefits to being able to RAID across controllers. A RAID controller is a single point of failure. If a controller fails on a HW raid system, your array goes down. On SW RAID (done properly) a single controller can go away without a problem.
The most reliable storage system we have (a Network Appliance rack) is entirely software RAID. (RAID 4, a number you don't hear often).
The Saturn 5 was a massive beast of a launcher, but they canned it after Apollo. With a heavy lifter like that, NASA could have launched the space station in half the time and much safer. And now they are redesigning the whole heavy-lift launch vehicle for the Moon project.
Thing like this keep getting repeated. There is no evidence that the Saturn V would have been any safer than the shuttle either in a similar number of launches or a with a similar number of people lifted to orbit. The same is true of any other expendible launch vehicle. In the commercial launch business 98% success rates are considered outstanding. When launching people, a 98% success rate is considered a dismal failure.
Please remember that the 13 "successful" Saturn V flights include one where the crew was nearly lost. It might be possible that the Saturn V would have had a long term 98% success rate. But all the numbers we have can tell is there's a 95% chance that its success rate would have been better than 80% and a 50% chance that it would have been better than 94.8%. But that also means theres a 50% chance that it would be lower than 94.8%.
The availability of PPC builds is encouraging. However, the lack of Universal Binary versions is not... I hope SETI will get Intel versions out quickly. It's been nearly seven months since the first Intel-based Macs were made available to the public.
There are intel mac versions available. The BOINC application is a universal binary which will request the correct version of SETI@home for the architecture used. See this page for the stock application list. (And yes, the intel mac version does use SSE for its FFTs).
Ummmm, the most recent stock SETI@home enhanced uses Altivec for FFT calculations. Better optimized versions for G4 and G5 are also available here if you want them.
I realize internet-linked PCs are a different beast, but given the wide range of architectures on the top 500 supercomputer list, is it such a stretch to consider this a "supercomputer"? Anyone know how the SETI@home project would place?
Someone would need to port LINPACK to BOINC in order to find out. Theoretical and real world performance are two different things. The average machine connected to SETI@home has a theoretical performance of about 1.2 GFLOP/s on non-vectorized code (based upon benchmarks of a sample of 605,000 hosts that have recently returned work). Let's assume we keep about 650,000 machines running continuously (or 1.3 million running half time). That would mean our theoretical performance is somewhere on the order of 780 TFLOP/s, which would rank us at the top.
But theoretical performance doesn't count when assembling the list. In actuality, the SETI@home application gets about 28.5% of the theoretical performance, or 222 TFLOP/s. Our long term average is 167 TFLOP/s. That would still put us at the top.
But performance in a specific application doesn't count. It's only LINPACK performance that counts.
Or, to put it another way, Buffett's job for the past several decades has been to manage other people's money in ways that were far more profitable than they could manage it themselves. In his mind, every dollar that he had was actually a dollar he was managing on behalf of the charity that would get his fortune when he died.
Tell that to people who died of malaria last year. It's great that he's doing this, but he certainly isn't going to discomfort himself when someone else's life is on the line.
For the religious among you, show me in your holy book where it says that it's OK not to give this year if you will give more next year.
I'm not religious, but the ethics I adhere to don't permit me to ignore suffering today if I promise to be generous when I get rich.
It's not a death tax, it's an estate tax. 99% of people who die don't pay it. Only those that leave large estates do. The myth that middle class households are affected by this tax is exactly that, a myth.
Frankly, there is no death tax, but there is a birth tax. Everyone born in this country is born with a large debt that eventually they will need to pay. The boomers don't really care about the national debt because their kids and grandkids will be the ones that pay for it.
My comment to the ultra-wealthy who wait until they are about to die before they put their excess to good use is... "You've had 10 billion dollars for 30 years and NOW you decide to put the excess to good use?!?!?! Where the hell were you last year?"
It's things like this that make me wish there were a god to teach them the error of their ways...
Let me turn this around for you. Imagine an uncritical report on Iraq being championed by a democrat and discussed on some right-leaning site:
All this proves is that some Democrats haven't gone totally batshit insane yet.
Is it suddenly looking a lot less objective to you? Care to guess why?
Not necessarily less objective, just wrong. The quote you should have put there is... "All this proves is that SOME Democrats HAVE gone totally batshit insane."
There are common standards of insanity. Some clinical symptoms of batshit insanity:
doing the same thing over and over and expecting a different result.
belief that invisible beings talk to you and exert control over your daily life.
acting on the instructions that your invisible friends give you.
belief that "freedom" means people are free to do what you want them to (or what your invisible friends tell them to do.)
belief that "tolerance" means that people should behave only in the ways that you tolerate.
pretending that things that happened right in front of you didn't happen, especially if your invisible friends say they didn't happen.
belief that 10% of the population is involved in a grand conspiracy to turn your kids into mindless zombies that are just like them.
belief that your marriage would fall apart if that 10% of the population could marry.
denying statements you have made even after seeing a video of yourself making the statements.
belief that you can kill the people you don't like because they might get a gun to defend themselves against you.
after acting on the above, belief that the rest of the people you don't like aren't going to head straight for a gun shop.
Is this how we will be warned if one is heading to hit the earth ? After the fact ? I don't understand we put so much money into that agency and yet they keep messing up. Come you rocket scentist get your game on.
Ummm, 4 tons TNT equivalent? Who cares. One of these hits us daily and we don't seem to notice.
20 kiloton airbursts (5000 times bigger, think Hiroshima) happen annually and we don't notice those.
The 20 megaton airbursts (5 million times bigger, think Tunguska) that happen every hundred years or so, those we notice, some of the time, maybe.
It's somewhere around 20 gigatons (5 billion times bigger) that we need to start worrying that more than a couple people might get hurt.
Let assume that someone will eventually develop a DNA matching scheme that is 99.9999% accurate, i.e. the chances of a false positive are one in a million. Now put the DNA patterns of everyone in the country in a database.
Now every time a murder occurs you search the database. And up pop about 350 names. Let's assume you put in some other criteria like location and limit it to people who live within 50 miles of where the murder occurred. If the place happens to be a large city (where the majority of murders occur) you're still talking about 10 names. But you can't be sure none of the other 340 people who match weren't in town on vacation.
Solving crimes needs to start with real police work. There's no getting around it. After the police work is done, and you have probably cause, then you can worry about finding out whether there is a DNA match. Starting out with a search of a massive database is sure to result in a lot of false accusations.
Say you used both the GPU and CPU at the same time, I would think you could search more data that way. I'm sure there's a penalty of some kind going to and from memory for both devices, but have you atleast considered the possibility?
We have considered the possibility. It seemed to us that the synchronization between the processing on the GPU and the CPU was the difficult part. The easiest method (and therefore the one that we would most likely have the time to implement) would be to have two copies of SETI@home running, one which uses the CPU only and one that uses the CPU plus the GPU for FFTs. You could come fairly close to keeping both the CPU and the GPU fully occupied.
We've got someone looking into using this FFT library. Technically it should be easy. Legally is another problem. This library is "free for non-commercial use" which is incompatible with the SETI@home license (GPL). We do include an exception to allow linking proprietary FFT libraries, but I'm not sure that the exception is fully compatible with this license since we can't control whether someone uses SETI@home in a commercial manner (although I don't see what commercial use they could find for it). I may have to contact the authors to discuss this.
If you are taking data off of some kind of sensor, there are damned few sensors with 24 good bits of data out of the noise floor. Radars work just fine with 16-bit A/D converters.
I think you are confusing the precision of the input data with the precision of the power spectrum. An FFTs do a scaled add of a large number of samples, so the precision in the output is dependent on the number of input samples.
For example SETI@home uses 1 bit complex sampling. (Yes, the SETI@home ADCs are a pair of high speed comparators.) That doesn't limit the results to 1 bit. It does reduce the sensitivity by 1.5dB (which, unfortunately isn't worth doubling our bandwidth or the number of tape we have to buy). The maximum precision you can get out of that in a 128K FFT (in the low SNR limit) is about 18 bits/channel or 54dB of dynamic range in the power spectrum. That's more than enough for SETI@home where our thresholds are at about 14dB. Changing that to a true 16bit ADC would give you 34 bits or 102dB at the expense of creating 16X as much data.
Of course depending upon the sampling rate and the duration of the signal you are looking for you may need the 16 bits. If you are looking over 8 samples you only get 4bits or 12dB for SETI@home, 20bits or 60dB for a 16bit ADC.
Yes, 32 bits is quite enough for our FFTs. Our requirements are fairly low. 16bit floats may even do the job (although I've never tried 16bit floats in SETI@home). What has concerned us in the past is that bandwidth to GPUs was fairly assymmetric (on AGP cards), the seti@home working sets (A few buffers of 1M complex samples == 16MB each) were larger than the usable memory on many video cards and the length of the maximum shader routine was fairly small. SETI@home does quite a bit more than FFTs, so moves into and out of main memory were required. At the time we couldn't put more into the shader language. That may have changed, but right now we lack anyone who both has the time to do the job and is capable of doing it.
Our tests on nVidia 5600 series AGP cards (this was several years ago) showed that the net SETI@home throughput using the GPU was at best 1/5 of what we could obtain with the CPU. This was primarily due to transfers out of graphics memory and into main memory.
PCI Express allows for symmetric bandwidth to graphics memory and graphics memories are now typically larger than the size of our working set. The difficulty will be in benchmarking to see which is faster for a specific GPU/CPU combination.
At any rate it's a fairly simple job to swap FFT routines in SETI@home. The source is available. Someone may have done it by now...
This brought to you by the same people who INSIST global warming is man-made and it's time to kill our economy by placing unnecessary restrictions on it.
Yeah, it's those same people who insist that poverty still exists in the U.S. and that the holocaust happened. Damn liberals even say that improving our energy efficiency while reducing greenhouse gasses will improve our economy. We all know that God controls the climate directly and that the rest of those things are liberal lies.
The world can take a lot more than we small humans are dishing out to it. The oceans alone can absorb 100 times more CO2 than we have ever pumped into the atmosphere without taking a blink. This is just more proof of nature's resilience. Don't bow to the environmentalist hype machine.
Yeah, who cares if the increasing oceanic acidity due to the absorbed CO2 prevents organisms from building the shells that would allow the CO2 to be deposited in ocean sediments. Just imagine water from your local reservoir being pre-carbonated. It'll be nice to have a cool fizzy beverage on the hot days to come.
Awful software: What did you expect, it ran on Windows 3.1. It was probably the only useful thing a home user ever ran on Windows 3.1
Sorry, early versions of AOL ran under a real operating system GEOS. GEOS ran windowed multitasking apps on an 8088 with a Motif interface. Of course, it wasn't compatible with Windows software. Then again, at the time, neither was Windows.
Partially, this seems to be the ethos of Google labs, where a third (I think) of developers' time is given over to their own projects.
A lot of companies have this type of policy. I once worked for a place that allowed employees to do anything they wanted with 20% of their time. Would you believe that some people actually used that 33.6 hours a week sleeping?
Should we just skip word processors and use that or LaTex?
Find me a wysiwyg html/css editor (that outputs nice clean css/html after being edited by 5 people) that my secretary can use (he's a liquid-paper on the screen type) and I'll support that.
It's weird. When I first came to work for my current employer we used to have something called an "editorial staff". That was back in the day when we were able to afford secretaries. (i.e Un the dark ages when document preparation was considered a skill requiring some training.) Back then all of our secretaries knew troff, TeX, and LaTeX. A large fraction of them could write shell scripts that would merge disparate inputs and output a TeX document (for example merging text into a fax cover page template).
Then WYSIWYG showed up. Document preparation tasks got easier for the untrained, but the duration of those task was vastly increased because the WYSIWYG word processor never quite did what you wanted the first time. Shortly thereafter it was decided that secretarial staff was too expensive, and so all the document preparation tasks were transitioned to engineers, scientists, and executives. We're told that this saves money, because apparently engineers, scientists, and executives don't have anything else they should be doing. Most of the trained document preparers were shoved out the door or transitioned into other work. Secretarial salaries stagnated and now you get fresh graduates from rodeo clown college that have never seen a computer when you try to hire one at such a pittance.
Maybe it would be better if we valued document preparation skills and payed accordingly. Maybe I'm just naive.
No it isn't. MAP_PRIVATE is a flag to mmap(). It says nothing about copy on write, it says not to share this page with any other processes that map the same file/region.
It's clear you don't know what you are talking about. That statement is just plain wrong.
% uname -sr
Linux 2.6.16-1.2096_FC4smp
% man mmap
. . . MAP_PRIVATE Create a private copy-on-write mapping. Stores to the region do not affect the original file. It is unspecified whether changes made to the file after the mmap call are visible in the mapped region.
. . .
Or you could look here...
If MAP_PRIVATE is specified, modifications to the mapped data by the calling process shall be visible only to the calling process and shall not change the underlying object. It is unspecified whether modifications to the underlying object done after the MAP_PRIVATE mapping is established are visible through the MAP_PRIVATE mapping.
Let me ask you two offtopic questions about the code you posted (I'm one of those stupid coders): if you allocate getpagesize(), aren't you actually allocating two pages? I mean, malloc needs to keep somewhere the size of how much memory you allocated, so you are actually using getpagesize() + bytes used by malloc implementation. Is this correct?
Actually I meant to write valloc() there, rather than vmalloc() since I was writing userland code rather than kernel code. (Apparently, I'm pretty stupid, too.)
Yes, the minimum actual allocation by valloc() is usually two pages, even if you only try to allocate 1 byte. It's usually the equivalient of calling memalign(getpagesize(),size) which is usually implemented over malloc(). It would be easy to concieve of an implementation that doesn't waste address space on mostly empty pages by storing the allocation information elsewhere.
I rarely use kmalloc() since I don't do much direct kernel hacking, but I'm fairly sure it allows sub-page allocations on a standard heap, as does malloc() and isn't guaranteed to be page aligned. kmalloc() is really only necessary when you want to get a physically adjacent physical pages for DMA, although __get_dma_pages() is a better bet. (I haven't done this in years, so those interfaces in the Linux kernel may have changed. Remember back when your DMA buffers needed to be in the lower 16MB of memory? Remember when they needed to be in the lowest 1MB?)
It's amazing what people don't understand about virtual memory implementations.
There isn't any such thing as a multiply mapped PROT_WRITE MAP_PRIVATE.
There certainly is. That what a copy-on-write page usually is. MAP_PRIVATE means shared until written.
If multiple processes have access to the same page allocated using mmap(), it was allocated using MAP_SHARED.
No. You've got that wrong. The difference between MAP_PRIVATE and MAP_SHARED is not whether the pages are shared or not, but whether changes to the page are shared. If you MAP_PRIVATE a page without PROT_WRITE, only one copy of that page will ever exist in memory regardless of how many processes map it. In other words without PROT_WRITE, there is no difference between a MAP_PRIVATE and a MAP_SHARED page. This is often how exectuables are mapped. The difference between MAP_PRIVATE and MAP_SHARED is whether changes to the page BY THE MAPPING PROCESS are shared. It's very important that an application developer understand this, or they are opening themselves up for problems.
For example, one process maps a page PROT_READ|PROT_WRITE and MAP_PRIVATE while another maps it PROT_READ|PROT_WRITE and MAP_SHARED. If the MAP_SHARED process writes to the page, under many (if not most) operating systems, the MAP_PRIVATE process WILL see the changes to the page. This is, so long as the MAP_PRIVATE process has not written to the page. Once the MAP_PRIVATE process writes to the page, a private copy of the page is made and the mapping between the original and the copy is lost. Following that point writes by the MAP_SHARED process will not be reflected in the MAP_PRIVATE copy. The copy is not necessarily (read usually not) made before the first write.
MAP_PRIVATE has nothing to do with faults.
It has everything to do with faults because the first write attempt to a writable MAP_PRIVATE page will almost certainly cause a copy-on-write fault.
MAP_PRIVATE isn't COW. It's not even related. MAP_PRIVATE is a flag for mmap() which has nothing at all to do with COW.
Is this your first experience with virtual memory? The combination of MAP_PRIVATE and PROT_WRITE is (generally) copy-on-write. (I say generally because I haven't used every single UNIX system that implements mmap(), just most of them.). The combination of MAP_PRIVATE or MAP_SHARED and not PROT_WRITE is segfault-on-write. The combination of MAP_SHARED and PROT_WRITE is no action on write.
Your example code isn't an example of zero_copy because the pages aren't touched.
I assume by touched you mean written? In such code fragments the comment "/* do stuff here */" usually implies that the page is written or read. But you are right that it shouldn't be an example of zero copy because there is no opportunity to read zeros from the page. If any operating system clears a page in my example, (unless the device we are reading is/dev/zero), it's a waste of time. I was discussing the generalities of VM rather than Linus's tirade.
Yes, sometimes copy on write of a zero page is a waste, but the time to solve that isn't necessarily when the page is mapped. The means of zeroing (and whether to zero) the page should be allowed to depend upon which device is being used. If it's an RS-232 port, who the hell cares whether the buffer page is copy-on-write. You're going to context switch a few hundred times between characters anyway. In some cases the best time to zero unused portions of a page might be AFTER the completion of the first write.
Every time VM gets discussed I become less impressed with kernel hackers and less impressed with coders in general. This goes for both Linux and the BSDs.
Why would anyone read into a buffer smaller than the VM page size? Why should data need to be copied in the first place?
size_t bufsiz=getpagesize(); char *buffer=vmalloc(bufsiz); int nread = 0; int length;
while(read < totalSize) { /* if fread() isn't directly remapping pages from a merged * freelist/diskcache into the address pointed to by buffer * then it's a stupid implementation. If you don't know * whether it's a stupid implementation call mmap() directly. */ #ifdef SMART_FREAD length = fread(buffer, 1, bufsiz, file); #else /* emulate fread with the VM subsystem */ if (buffer) munmap(buffer,bufsiz); buffer = mmap(buffer,bufsiz,PROT_READ|PROT_WRITE,MAP_PRIVAT E,fileno(file),nread); /* With proper read-ahead by the cache subsystem this should not */ /* cause a page fault on every mapping unless you write to this page. */ /* If it does, copy-on-write is the least of your worries. */ if (buffer) { length=bufsiz; } else { length=0; } #endif if (length) { /* do stuff */ nread += length; } }
If there's a signficant difference between the performance depending upon whether SMART_FREAD is defined, then there are problems with the either the VM or I/O implementation. From the sound of it, unless Linus is defining a flag to the mmap call, he's making a copy of every multiply mapped PROT_WRITE, MAP_PRIVATE page whether it gets written to or not, which means large PROT_WRITE, MAP_PRIVATE mappings use more memory but page fault less. In BSD, you get more page faults but use less memory. Each has advantages depending upon the application. Neither requires calling the user of the other an imbecile.
In a large memory machine with moderate size "write often" memory allocations (i.e. the typical desktop) the Linux scheme would have benefits. In machine that uses datasets much larger than memory that are written rarely, the COW scheme has benefits. An example would be a large page-locked database where the page fault and page lock mechanisms are intertwined.
The proper thing would be to split MAP_PRIVATE into two options MAP_PRIVATE_COW and MAP_PRIVATE_COM (COM=copy on map) with MAP_PRIVATE being defined to one or the other. Whether Linux will be giving user mode applications the option of one or the other, I don't know. I certainly hope it's not going to be a separate userland API from mmap().
Slashdot Mirror
Really? I've still got bulbs I purchased in around 1992 that are still working. The biggest problem I've had is that they dim as the years march on and get moved to places that require less light.
I have had some last less than a year, but I've found that those are related more to the fixture used than the bulb. Enclosed fixtures especially those with multiple bulbs will reduce the lifetime due to trapped heat. Any fixture where the bulb doesn't fit well and ends up under stress is also a bulb killer.
The biggest problem I have with compact fluorescents is the accumulation of dead bugs in ceiling fixtures. With incandescent bulbs the changes are frequent enough that bugs don't have time to accumulate.
Campbell's thesis is essentially that there is only one story in mythology: "Teenage boy finds finds he is of noble/royal/divine/magic blood and is sent by the gods/elders/wizards on a difficult and dangerous quest to defeat bad guys/rescue hot chick/retrieve magic item/destroy magic item/avenge death of his father."
That would be an OK thesis if it had been left there... Unfortunately it is extended to saying that there is something about this story that is ingrained in our psyche or the "collective unconscious" and that all stories should follow this format because this is obviously what we all want. The antithesis to this is that since we're bombarded with stories of this type from a early age and people gravitate to them because of their familiarity.
It is rarely mentioned that these stories were crafted by people under the rule of a chiefain that considered himself of noble/royal/divine blood. Stories of this type were "popular" for a few related reasons. 1) By glofiying the "noble blood" flowing in the veins of the cheiftain the author earns favor and is less likely to find his head decorating a pike outside the cheiftain's den. 2) The stories serve the purpose of the chieftain by creating fear of the "awsome powers" of the nobility and perpetuating the myth of the "divine right" of those of noble blood to rule.
Personally, I rarely enjoy stories that directly follow this formula. I prefer stories where the hero/heroine denies his/her noble heritage in favor of more egalitarian values and the fight is against the nobility rather than perpetuating it. Either that, or tragedies where the hero's noble blood works to cause his downfall. I hope the ancient "formula" is losing popularity among democratic societies. Some examples indicate this might not be the case, however.
Harry Potter is yet another "chosen one". There's still another book left in which he could renounce magic and obedience to the high wizards then shoot Valdemort in the head with a .45, but I doubt that's going to happen. The Star Wars saga ends with the return of the "noble blooded" priesthood class not to mention planets so under the spell of the nobility that they "elect" ultra rich 15 year old girls as rulers. Was Amidala really suited to rule, or was she the Paris Hilton of Naboo? The house in the lake country would seem to indicate the latter...
I can give you a few reasons they might. Having been through some hardware RAID nightmares I have first hand experience with a few of them.
HW RAID makes you dependent upon the manufacturer of the card both for RAID implementation and for drivers. We once a a couple hardware RAID cards managing a large (at the time) RAID0+1 array that would occasionally glitch and fail a drive or two (or occasionally every drive on the controller). The driver and monitoring daemon wouldn't report anything until a second drive failed. Despite battery backup on the card cache, a single drive failure would often corrupt the data on the mirrored drive. The manufacturer was nowhere to be found when requesting updates or bug fixes.
We eventually switched to software RAID and found that in addition to making the array reliable it improved our performance. This was in part because the 6 CPUs on the machine were significantly faster than the 25MHz i960 managing the RAID cards. We could also mirror across controllers on the 4 separate PCI busses which gets rid of a major bottleneck (the I/O on a PCI bus can be easily saturated by a few drives)).
There are other benefits to being able to RAID across controllers. A RAID controller is a single point of failure. If a controller fails on a HW raid system, your array goes down. On SW RAID (done properly) a single controller can go away without a problem.
The most reliable storage system we have (a Network Appliance rack) is entirely software RAID. (RAID 4, a number you don't hear often).
Thing like this keep getting repeated. There is no evidence that the Saturn V would have been any safer than the shuttle either in a similar number of launches or a with a similar number of people lifted to orbit. The same is true of any other expendible launch vehicle. In the commercial launch business 98% success rates are considered outstanding. When launching people, a 98% success rate is considered a dismal failure.
Please remember that the 13 "successful" Saturn V flights include one where the crew was nearly lost. It might be possible that the Saturn V would have had a long term 98% success rate. But all the numbers we have can tell is there's a 95% chance that its success rate would have been better than 80% and a 50% chance that it would have been better than 94.8%. But that also means theres a 50% chance that it would be lower than 94.8%.
There are intel mac versions available. The BOINC application is a universal binary which will request the correct version of SETI@home for the architecture used. See this page for the stock application list. (And yes, the intel mac version does use SSE for its FFTs).
Ummmm, the most recent stock SETI@home enhanced uses Altivec for FFT calculations. Better optimized versions for G4 and G5 are also available here if you want them.
SETI@home is GPL. Has been for some time. BOINC is LGPL. Has been for some time.
Which are "those" clients that you are talking about?
Sorry, should have said "near" rather than "at" the top when discussing the 222 TFLOP and 167 TFLOP numbers.
Someone would need to port LINPACK to BOINC in order to find out. Theoretical and real world performance are two different things. The average machine connected to SETI@home has a theoretical performance of about 1.2 GFLOP/s on non-vectorized code (based upon benchmarks of a sample of 605,000 hosts that have recently returned work). Let's assume we keep about 650,000 machines running continuously (or 1.3 million running half time). That would mean our theoretical performance is somewhere on the order of 780 TFLOP/s, which would rank us at the top.
But theoretical performance doesn't count when assembling the list. In actuality, the SETI@home application gets about 28.5% of the theoretical performance, or 222 TFLOP/s. Our long term average is 167 TFLOP/s. That would still put us at the top.
But performance in a specific application doesn't count. It's only LINPACK performance that counts.
Tell that to people who died of malaria last year. It's great that he's doing this, but he certainly isn't going to discomfort himself when someone else's life is on the line.
For the religious among you, show me in your holy book where it says that it's OK not to give this year if you will give more next year.
I'm not religious, but the ethics I adhere to don't permit me to ignore suffering today if I promise to be generous when I get rich.
Frankly, there is no death tax, but there is a birth tax. Everyone born in this country is born with a large debt that eventually they will need to pay. The boomers don't really care about the national debt because their kids and grandkids will be the ones that pay for it.
My comment to the ultra-wealthy who wait until they are about to die before they put their excess to good use is... "You've had 10 billion dollars for 30 years and NOW you decide to put the excess to good use?!?!?! Where the hell were you last year?"
It's things like this that make me wish there were a god to teach them the error of their ways...
Not necessarily less objective, just wrong. The quote you should have put there is... "All this proves is that SOME Democrats HAVE gone totally batshit insane."
There are common standards of insanity. Some clinical symptoms of batshit insanity:
Ummm, 4 tons TNT equivalent? Who cares. One of these hits us daily and we don't seem to notice.
20 kiloton airbursts (5000 times bigger, think Hiroshima) happen annually and we don't notice those.
The 20 megaton airbursts (5 million times bigger, think Tunguska) that happen every hundred years or so, those we notice, some of the time, maybe.
It's somewhere around 20 gigatons (5 billion times bigger) that we need to start worrying that more than a couple people might get hurt.
Now every time a murder occurs you search the database. And up pop about 350 names. Let's assume you put in some other criteria like location and limit it to people who live within 50 miles of where the murder occurred. If the place happens to be a large city (where the majority of murders occur) you're still talking about 10 names. But you can't be sure none of the other 340 people who match weren't in town on vacation. Solving crimes needs to start with real police work. There's no getting around it. After the police work is done, and you have probably cause, then you can worry about finding out whether there is a DNA match. Starting out with a search of a massive database is sure to result in a lot of false accusations.
We have considered the possibility. It seemed to us that the synchronization between the processing on the GPU and the CPU was the difficult part. The easiest method (and therefore the one that we would most likely have the time to implement) would be to have two copies of SETI@home running, one which uses the CPU only and one that uses the CPU plus the GPU for FFTs. You could come fairly close to keeping both the CPU and the GPU fully occupied.
We've got someone looking into using this FFT library. Technically it should be easy. Legally is another problem. This library is "free for non-commercial use" which is incompatible with the SETI@home license (GPL). We do include an exception to allow linking proprietary FFT libraries, but I'm not sure that the exception is fully compatible with this license since we can't control whether someone uses SETI@home in a commercial manner (although I don't see what commercial use they could find for it). I may have to contact the authors to discuss this.
I think you are confusing the precision of the input data with the precision of the power spectrum. An FFTs do a scaled add of a large number of samples, so the precision in the output is dependent on the number of input samples.
For example SETI@home uses 1 bit complex sampling. (Yes, the SETI@home ADCs are a pair of high speed comparators.) That doesn't limit the results to 1 bit. It does reduce the sensitivity by 1.5dB (which, unfortunately isn't worth doubling our bandwidth or the number of tape we have to buy). The maximum precision you can get out of that in a 128K FFT (in the low SNR limit) is about 18 bits/channel or 54dB of dynamic range in the power spectrum. That's more than enough for SETI@home where our thresholds are at about 14dB. Changing that to a true 16bit ADC would give you 34 bits or 102dB at the expense of creating 16X as much data.
Of course depending upon the sampling rate and the duration of the signal you are looking for you may need the 16 bits. If you are looking over 8 samples you only get 4bits or 12dB for SETI@home, 20bits or 60dB for a 16bit ADC.
Our tests on nVidia 5600 series AGP cards (this was several years ago) showed that the net SETI@home throughput using the GPU was at best 1/5 of what we could obtain with the CPU. This was primarily due to transfers out of graphics memory and into main memory.
PCI Express allows for symmetric bandwidth to graphics memory and graphics memories are now typically larger than the size of our working set. The difficulty will be in benchmarking to see which is faster for a specific GPU/CPU combination.
At any rate it's a fairly simple job to swap FFT routines in SETI@home. The source is available. Someone may have done it by now...
Yeah, it's those same people who insist that poverty still exists in the U.S. and that the holocaust happened. Damn liberals even say that improving our energy efficiency while reducing greenhouse gasses will improve our economy. We all know that God controls the climate directly and that the rest of those things are liberal lies.
The world can take a lot more than we small humans are dishing out to it. The oceans alone can absorb 100 times more CO2 than we have ever pumped into the atmosphere without taking a blink. This is just more proof of nature's resilience. Don't bow to the environmentalist hype machine.
Yeah, who cares if the increasing oceanic acidity due to the absorbed CO2 prevents organisms from building the shells that would allow the CO2 to be deposited in ocean sediments. Just imagine water from your local reservoir being pre-carbonated. It'll be nice to have a cool fizzy beverage on the hot days to come.
Sorry, early versions of AOL ran under a real operating system GEOS. GEOS ran windowed multitasking apps on an 8088 with a Motif interface. Of course, it wasn't compatible with Windows software. Then again, at the time, neither was Windows.
A lot of companies have this type of policy. I once worked for a place that allowed employees to do anything they wanted with 20% of their time. Would you believe that some people actually used that 33.6 hours a week sleeping?
It's weird. When I first came to work for my current employer we used to have something called an "editorial staff". That was back in the day when we were able to afford secretaries. (i.e Un the dark ages when document preparation was considered a skill requiring some training.) Back then all of our secretaries knew troff, TeX, and LaTeX. A large fraction of them could write shell scripts that would merge disparate inputs and output a TeX document (for example merging text into a fax cover page template).
Then WYSIWYG showed up. Document preparation tasks got easier for the untrained, but the duration of those task was vastly increased because the WYSIWYG word processor never quite did what you wanted the first time. Shortly thereafter it was decided that secretarial staff was too expensive, and so all the document preparation tasks were transitioned to engineers, scientists, and executives. We're told that this saves money, because apparently engineers, scientists, and executives don't have anything else they should be doing. Most of the trained document preparers were shoved out the door or transitioned into other work. Secretarial salaries stagnated and now you get fresh graduates from rodeo clown college that have never seen a computer when you try to hire one at such a pittance.
Maybe it would be better if we valued document preparation skills and payed accordingly. Maybe I'm just naive.
It's clear you don't know what you are talking about. That statement is just plain wrong.
% uname -sr
Linux 2.6.16-1.2096_FC4smp
% man mmap
. . .
MAP_PRIVATE Create a private copy-on-write mapping. Stores to the region do not affect the original file. It is unspecified whether changes made to the file after the mmap call are visible in the mapped region.
. . .
Or you could look here... If MAP_PRIVATE is specified, modifications to the mapped data by the calling process shall be visible only to the calling process and shall not change the underlying object. It is unspecified whether modifications to the underlying object done after the MAP_PRIVATE mapping is established are visible through the MAP_PRIVATE mapping.
Actually I meant to write valloc() there, rather than vmalloc() since I was writing userland code rather than kernel code. (Apparently, I'm pretty stupid, too.)
Yes, the minimum actual allocation by valloc() is usually two pages, even if you only try to allocate 1 byte. It's usually the equivalient of calling memalign(getpagesize(),size) which is usually implemented over malloc(). It would be easy to concieve of an implementation that doesn't waste address space on mostly empty pages by storing the allocation information elsewhere.
I rarely use kmalloc() since I don't do much direct kernel hacking, but I'm fairly sure it allows sub-page allocations on a standard heap, as does malloc() and isn't guaranteed to be page aligned. kmalloc() is really only necessary when you want to get a physically adjacent physical pages for DMA, although __get_dma_pages() is a better bet. (I haven't done this in years, so those interfaces in the Linux kernel may have changed. Remember back when your DMA buffers needed to be in the lower 16MB of memory? Remember when they needed to be in the lowest 1MB?)
There isn't any such thing as a multiply mapped PROT_WRITE MAP_PRIVATE.
There certainly is. That what a copy-on-write page usually is. MAP_PRIVATE means shared until written.
If multiple processes have access to the same page allocated using mmap(), it was allocated using MAP_SHARED.
No. You've got that wrong. The difference between MAP_PRIVATE and MAP_SHARED is not whether the pages are shared or not, but whether changes to the page are shared. If you MAP_PRIVATE a page without PROT_WRITE, only one copy of that page will ever exist in memory regardless of how many processes map it. In other words without PROT_WRITE, there is no difference between a MAP_PRIVATE and a MAP_SHARED page. This is often how exectuables are mapped. The difference between MAP_PRIVATE and MAP_SHARED is whether changes to the page BY THE MAPPING PROCESS are shared. It's very important that an application developer understand this, or they are opening themselves up for problems.
For example, one process maps a page PROT_READ|PROT_WRITE and MAP_PRIVATE while another maps it PROT_READ|PROT_WRITE and MAP_SHARED. If the MAP_SHARED process writes to the page, under many (if not most) operating systems, the MAP_PRIVATE process WILL see the changes to the page. This is, so long as the MAP_PRIVATE process has not written to the page. Once the MAP_PRIVATE process writes to the page, a private copy of the page is made and the mapping between the original and the copy is lost. Following that point writes by the MAP_SHARED process will not be reflected in the MAP_PRIVATE copy. The copy is not necessarily (read usually not) made before the first write.
MAP_PRIVATE has nothing to do with faults.
It has everything to do with faults because the first write attempt to a writable MAP_PRIVATE page will almost certainly cause a copy-on-write fault.
MAP_PRIVATE isn't COW. It's not even related. MAP_PRIVATE is a flag for mmap() which has nothing at all to do with COW.
Is this your first experience with virtual memory? The combination of MAP_PRIVATE and PROT_WRITE is (generally) copy-on-write. (I say generally because I haven't used every single UNIX system that implements mmap(), just most of them.). The combination of MAP_PRIVATE or MAP_SHARED and not PROT_WRITE is segfault-on-write. The combination of MAP_SHARED and PROT_WRITE is no action on write.
Your example code isn't an example of zero_copy because the pages aren't touched.
I assume by touched you mean written? In such code fragments the comment "/* do stuff here */" usually implies that the page is written or read. But you are right that it shouldn't be an example of zero copy because there is no opportunity to read zeros from the page. If any operating system clears a page in my example, (unless the device we are reading is /dev/zero), it's a waste of time. I was discussing the generalities of VM rather than Linus's tirade.
Yes, sometimes copy on write of a zero page is a waste, but the time to solve that isn't necessarily when the page is mapped. The means of zeroing (and whether to zero) the page should be allowed to depend upon which device is being used. If it's an RS-232 port, who the hell cares whether the buffer page is copy-on-write. You're going to context switch a few hundred times between characters anyway. In some cases the best time to zero unused portions of a page might be AFTER the completion of the first write.
In a large memory machine with moderate size "write often" memory allocations (i.e. the typical desktop) the Linux scheme would have benefits. In machine that uses datasets much larger than memory that are written rarely, the COW scheme has benefits. An example would be a large page-locked database where the page fault and page lock mechanisms are intertwined.
The proper thing would be to split MAP_PRIVATE into two options MAP_PRIVATE_COW and MAP_PRIVATE_COM (COM=copy on map) with MAP_PRIVATE being defined to one or the other. Whether Linux will be giving user mode applications the option of one or the other, I don't know. I certainly hope it's not going to be a separate userland API from mmap().