MySQL is the backend on them all, too. Works great for what they need.
Good for you. Frankly, I think that in many cases the features of MySQL would be enough for me too. Now let me explain why I prefer PostgreSQL:
1. I've used both, and IMHO both are about equally easy to use. So at least for me, the often made claim that MySQL is easier to use is bollocks.
2. I don't run the DB on Windows, so the fact that MySQL has a native Windows port and PostgreSQL hasn't, doesn't bother me. If you care, the next PostgreSQL release is supposed to include a native Windows version.
3. The PostgreSQL client libraries are BSD, while the MySQL libraries are GPL. If I make commercial apps, I would have to buy a commercial license from MySQL Ab.
4. MySQL is often supposed to have superior performance compared to PostgreSQL in the case of a single user doing simple queries. But IMHO this doesn't really matter, since in almost all cases a single user doing simple queries means a simple application, where any low end PC provides enough juice. Where performance matters is a situation with many users doing complicated queries (including writes as well as reads), a situation that PostgreSQL handles much better than MySQL.
5. Features. The PostgreSQL query language supports a much larger subset of the latest SQL standard (SQL:2003) than MySQL. If I find that I need some specific feature, it is quite probable that it exists in PostgreSQL but not in MySQL. Such as subselects, how can you live without them? And no, beta versions of MySQL don't count. Or stored procedures.
6. ACID properties, something that the PostgreSQL development team takes very seriously. E.g. does MySQL check foreign key constraints, or are they still no-ops?
In short, I feel that MySQL provides no benefit compared to PostgreSQL at the low end (such as ease of use etc.), and if you need more high-end features you'll run out of steam with MySQL way before PostgreSQL does.
A nuclear reactor (maybe supercritical?) can do much worse, and these things do happen at some point--No matter how good security can be, there is no such thing as 100% safety.
Aside from the fact that nuclear reactors don't go supercritical, what do you think is the worst case scenario?
I'd say that Chernobyl is about as bad as it gets. Basically the entire reactor exploded, and there was no containment building so everything was spewed into the environment. So, what were these city-destroying effects of Chernobyl? Well, about 30 persons died in the direct aftermath (mostly firemen). There has been a statistically measurable increase of thyroid cancer in children, so far an estimated 10 children have died from this. Apart from that, well, nothing. If you don't trust me, please check the reports by UNSCEAR and WHO, which to my knowledge are the authorative reports in this area.
Additionally, if you accept the linear model of low dose damage, there will be an estimated 10000-100000 deaths during the 80 years following the accident. This may sound like much, but consider that during the same time period about 60 million persons of the same population will die from cancer. These 100000 deaths, while of course very unfortunate, cannot even be distinguished from the noise.
Now, at this point mankind has about 10000 reactor-years of operating experience. We've had one really serious accident which has left 40 persons dead, and an estimated 10000 -> 100000 statistical deaths during the 80 years following the accident. I'd say that is a remarkably good record.
Contrast this with fossil fuels, where only in Europe an estimated 100000 persons die an early death EACH YEAR due to airborne pollutants.
CANDU, not enriched, because CANDU burns natural uranium unlike the stoopid USA enriched reactors which I think were designed that way to justify enrichment facilities so bombs could be made
Actually, the newest CANDU design requires enriched fuel. Any why, one might ask? Because after the cold war there is an abundance of enriched uranium lying around. Using that fuel for reactors is a better idea than waiting until Osama & Co. steal it. Secondly, with enriched uranium the reactor can be made smaller and cheaper for the same power output.
Turns out that your former president Clinton didn't fancy nuclear energy, so he shut down a lot of innovative nuclear energy research projects. Including the EBR-II / IFR thing you linked to.
Gee, I wonder how much longer he's gonna be around at MS.
His name is Bob.. and has been at MS for 16 years. You know, perhaps he was the mastermind behind Microsoft Bob? They can't afford to lose talent like that!;=)
In some places of the world, it is forbidden to use the solid matter as fertilizer, so it's burned instead (and the heat used for district heating or something like that).
With increasing caution against potential environmental dangers from this waste, such as heavy metal content, unpleasant bacteria which in some worst-case scenario could circulate back to the human foodchain, hormones etc. from all the pills people eat for all kinds of reasons, I think that such legislation will become increasingly common.
Heh.. This reminds me of my mums former co-worker (a woman, in her late thirties IIRC) who had a really old crappy car. Well, eventually she bought a new one. And she drove the new car until she ran out of gas, at which point she called some service company which came and refilled for her.
Next day at the office: "Gee, I ran out of gas yesterday. I thought that these new modern cars didn't need to be refilled."
The military controllers were all in Ada, the civilian engine controllers were in various things, with C/C++ heavily represented. The team capabilities were about equal across the board. After they crunched the data down, they discovered that Ada was giving them twice the programmer productivity and 1/4 the defect density.
On an offtopic note, I remember a study comparing Fortran 77 and C in a scientific/techical setting, and the conclusion of that was that Fortran codes had 1/2 the defects of comparable C codes.
C/C++ does have its uses, but writing reliable, easy to maintain software doesn't seem to be one of them.
In the Opteron case, the memory is still relatively local, and based on the benchmarks in the article the performance hit for accessing another CPU's memory is not huge.
Remember that the Opteron has an on-chip memory manager (MMU). Consider a system with two cpus, CPU#0 and CPU#1. The architecture, AFAIK, is that each CPU has one HyperTransport link to its own memory, and another HyperTransport link to the other CPU. So, if CPU#0 finds that it needs to access memory local to CPU#1 it needs to go through
This will certainly increase latency as well as reducing the memory bandwidth available to CPU#1 (since CPU#0 is also using MMU#1).
In general, I think these systems are treated as SMP, with one large memory space.
Well, having a shared memory is the basic idea behind using a NUMA in the first place..
My question is how difficult is a memory affinity implementation, and is it worth the overhead/complexity?
Linux, at least, already has NUMA support, originally for the big SGI machines. So the "complexity price" has already been paid. Obviously, cycles are used executing the NUMA logic in the kernel (when NUMA support is enabled, that is), but I guess that overhead is vanishingly small compared to the overhead of accessing potentially Gigabytes of non-local memory.
This problem does not arise however when we use 'double long' formats, or 64-bit floats, because these are way more precise and still can go a long way when 32-bit doubles already jump to zero, thus causing the problems.
On the x86 architecture, "long double" is 80-bit, and not 64-bit, which is plain "double". "float" is 32-bit.
However, note that the x86 does all floating point operations with 80-bit precision. So you don't get any performance advantage from using only single precision variables (other than lower memory bandwidth usage). Thus, a good rule of thumb is to always use double (long double might be better but isn't portable, and SSE doesn't support it if you want to use that). Single precision is mainly useful when you want to store large amounts of data (remember to cast the part of the data you're working on to double before calculating).
As others have pointed out, currently the Opteron is quite unbeatable in price/performance. 10000 EUR should certainly get you a 2 cpu system. Probably not 4 cpu:s though? Given that you need lots of memory, especially avoid the Xeon (or some other 32-bit architecture). Linux can only give 3 GB to one process with it's default configuration (I guess windows is similar?). With the so-called 4g/4g patch you can allow 4 GB for each process, but the price is lower performance. With a 64-bit architecture all those problems disappear.
Not so fast, a significant problem in such a comparison is that gcc has *much* better support for x86-64 than it does for PPC64.
Well, lots of reviews trashing ppc64 sounds like a good incentive for apple to help out the gcc project then. BTW, doesn't apple use gcc as the system compiler for OS X? In that case, you can't even dismiss gcc performance as only something those dirty GNU/hippies care about.
It takes a tremendous amount of energy and materials to synthesize hydrocarbons.
Why should it take any more than producing hydrogen through electrolysis? Of course, today hydrogen is cheaper when produced from natural gas, but in a future when we can't use fossil fuel either because we've run out of them or due to global warming or whatever, hydrogen will have to be produced from biomass, electrolysis or some such method. Just like hydrocarbons. Given a source of hydrogen (e.g. electrolysis) and a source of carbon (e.g. biomass or some industrial process producing CO2 such as making iron or a waste incinerator) one can produce hydrocarbon fuel with e.g. Fischer-Tropsch synthesis at a quite high efficiency of about 60 %. If we imagine a future world, with clean and abundant electricity produced by fusion and solar, it is feasible to improve this efficiency to almost 100 %, save some small heat losses.
An interesting article about the problems facing an energy economy based on elemental hydrogen, as opposed to synthetic hydrocarbons, is here. I highly recommend it.
They used Fischer-Tropsch synthesis. With that, given a source of coal and a source of hydrogen, you can produce almost any kind of hydrogen chain (efficiency of course varying a lot depending on the input and the wanted output). IIRC the Nazis used coal (you know, the black thing you mine and burn, as well as the element) for coal, and water for the hydrogen source and produced gasoline. The gasoline wasn't probably up to today's standard, but technology has improved so today you can make gasoline about as good as the usual dead dino stuff we use.
Do some google searching, there is quite a lot of research going on to use Fischer-Tropsch to produce renewable fuels.
Actually, diesel has slightly higher energy density than gasoline.
Personally, I don't see any kind of hydrogen storage becoming anyway near competetive with good old hydrocarbons. In the future we'll probably drive cars that still use hydrocarbon fuels, but use fuel cells instead of internal combustion engines. And the hydrocarbon fuel will be some kind of renewable or synthetic fuel instead of dead dinosaurs.
Re:Start by banning plastics for consumables
on
Out of Gas
·
· Score: 1
Yeah, better to burn that petroleum. The sooner the better.
Anyway, seriously, there was a quite big study a few years ago comparing lifecycle enviromental impacts of plastic, aluminium and glass for packaging beverages. The result was inconclusive; depending on what factors you valued more (e.g. priorize raw material consumption, energy consumption, etc.) than others any of the three options would come out on top.
Slashdot Mirror
MySQL is the backend on them all, too. Works great for what they need.
Good for you. Frankly, I think that in many cases the features of MySQL would be enough for me too. Now let me explain why I prefer PostgreSQL:
1. I've used both, and IMHO both are about equally easy to use. So at least for me, the often made claim that MySQL is easier to use is bollocks.
2. I don't run the DB on Windows, so the fact that MySQL has a native Windows port and PostgreSQL hasn't, doesn't bother me. If you care, the next PostgreSQL release is supposed to include a native Windows version.
3. The PostgreSQL client libraries are BSD, while the MySQL libraries are GPL. If I make commercial apps, I would have to buy a commercial license from MySQL Ab.
4. MySQL is often supposed to have superior performance compared to PostgreSQL in the case of a single user doing simple queries. But IMHO this doesn't really matter, since in almost all cases a single user doing simple queries means a simple application, where any low end PC provides enough juice. Where performance matters is a situation with many users doing complicated queries (including writes as well as reads), a situation that PostgreSQL handles much better than MySQL.
5. Features. The PostgreSQL query language supports a much larger subset of the latest SQL standard (SQL:2003) than MySQL. If I find that I need some specific feature, it is quite probable that it exists in PostgreSQL but not in MySQL. Such as subselects, how can you live without them?
And no, beta versions of MySQL don't count. Or stored procedures.
6. ACID properties, something that the PostgreSQL development team takes very seriously. E.g. does MySQL check foreign key constraints, or are they still no-ops?
In short, I feel that MySQL provides no benefit compared to PostgreSQL at the low end (such as ease of use etc.), and if you need more high-end features you'll run out of steam with MySQL way before PostgreSQL does.
It's a pity each of them aren't more compliant with the now 12 year old SQL-92 standard or the now 5 year old SQL-99 standard.
Not to mention the brand spanking new SQL:2003 standard, see e.g. this overview of the new features.
It's not like this is some surprising new insight, see another article posted today: here.
Oops. Sorry, I don't know where I got that idea from.
A nuclear reactor (maybe supercritical?) can do much worse, and these things do happen at some point--No matter how good security can be, there is no such thing as 100% safety.
Aside from the fact that nuclear reactors don't go supercritical, what do you think is the worst case scenario?
I'd say that Chernobyl is about as bad as it gets. Basically the entire reactor exploded, and there was no containment building so everything was spewed into the environment. So, what were these city-destroying effects of Chernobyl? Well, about 30 persons died in the direct aftermath (mostly firemen). There has been a statistically measurable increase of thyroid cancer in children, so far an estimated 10 children have died from this. Apart from that, well, nothing. If you don't trust me, please check the reports by UNSCEAR and WHO, which to my knowledge are the authorative reports in this area.
Additionally, if you accept the linear model of low dose damage, there will be an estimated 10000-100000 deaths during the 80 years following the accident. This may sound like much, but consider that during the same time period about 60 million persons of the same population will die from cancer. These 100000 deaths, while of course very unfortunate, cannot even be distinguished from the noise.
Now, at this point mankind has about 10000 reactor-years of operating experience. We've had one really serious accident which has left 40 persons dead, and an estimated 10000 -> 100000 statistical deaths during the 80 years following the accident. I'd say that is a remarkably good record.
Contrast this with fossil fuels, where only in Europe an estimated 100000 persons die an early death EACH YEAR due to airborne pollutants.
CANDU, not enriched, because CANDU burns natural uranium unlike the stoopid USA enriched reactors which I think were designed that way to justify enrichment facilities so bombs could be made
Actually, the newest CANDU design requires enriched fuel. Any why, one might ask? Because after the cold war there is an abundance of enriched uranium lying around. Using that fuel for reactors is a better idea than waiting until Osama & Co. steal it. Secondly, with enriched uranium the reactor can be made smaller and cheaper for the same power output.
Turns out that your former president Clinton didn't fancy nuclear energy, so he shut down a lot of innovative nuclear energy research projects. Including the EBR-II / IFR thing you linked to.
... and back in the real world, optimism only gets you so far.
We (the UK) probably take it off them for reprocessing at Sellafield
No, the French have their own reprocessing plant, close to Le Havre.
The article asked:
:)
What are the long term implications for quality of life?"
The answer being, in the long term you die, schizophrenia or not.
Which doesn't really have any impact on the rest of the universe, but that's just the way it is.
Gee, I wonder how much longer he's gonna be around at MS.
His name is Bob.. and has been at MS for 16 years. You know, perhaps he was the mastermind behind Microsoft Bob? They can't afford to lose talent like that!
IIRC lots of churches and such things are heated in part by heat from their crematorys.
In some places of the world, it is forbidden to use the solid matter as fertilizer, so it's burned instead (and the heat used for district heating or something like that).
With increasing caution against potential environmental dangers from this waste, such as heavy metal content, unpleasant bacteria which in some worst-case scenario could circulate back to the human foodchain, hormones etc. from all the pills people eat for all kinds of reasons, I think that such legislation will become increasingly common.
Heh.. This reminds me of my mums former co-worker (a woman, in her late thirties IIRC) who had a really old crappy car. Well, eventually she bought a new one. And she drove the new car until she ran out of gas, at which point she called some service company which came and refilled for her.
Next day at the office: "Gee, I ran out of gas yesterday. I thought that these new modern cars didn't need to be refilled."
Oh, the humanity...
The military controllers were all in Ada, the civilian engine controllers were in various things, with C/C++ heavily represented. The team capabilities were about equal across the board. After they crunched the data down, they discovered that Ada was giving them twice the programmer productivity and 1/4 the defect density.
On an offtopic note, I remember a study comparing Fortran 77 and C in a scientific/techical setting, and the conclusion of that was that Fortran codes had 1/2 the defects of comparable C codes.
C/C++ does have its uses, but writing reliable, easy to maintain software doesn't seem to be one of them.
But, it's not a typical NUMA architecture, is it?
I'm no expert on this, but I guess you're right.
In the Opteron case, the memory is still relatively local, and based on the benchmarks in the article the performance hit for accessing another CPU's memory is not huge.
Remember that the Opteron has an on-chip memory manager (MMU). Consider a system with two cpus, CPU#0 and CPU#1. The architecture, AFAIK, is that each CPU has one HyperTransport link to its own memory, and another HyperTransport link to the other CPU. So, if CPU#0 finds that it needs to access memory local to CPU#1 it needs to go through
CPU#0 -> MMU#0 -> HyperTransport -> MMU#1 -> HyperTransport -> Memory
instead of the direct route which is
CPU#0 -> MMU#0 -> HyperTransport -> Memory
This will certainly increase latency as well as reducing the memory bandwidth available to CPU#1 (since CPU#0 is also using MMU#1).
In general, I think these systems are treated as SMP, with one large memory space.
Well, having a shared memory is the basic idea behind using a NUMA in the first place..
My question is how difficult is a memory affinity implementation, and is it worth the overhead/complexity?
Linux, at least, already has NUMA support, originally for the big SGI machines. So the "complexity price" has already been paid. Obviously, cycles are used executing the NUMA logic in the kernel (when NUMA support is enabled, that is), but I guess that overhead is vanishingly small compared to the overhead of accessing potentially Gigabytes of non-local memory.
This problem does not arise however when we use 'double long' formats, or 64-bit floats, because these are way more precise and still can go a long way when 32-bit doubles already jump to zero, thus causing the problems.
On the x86 architecture, "long double" is 80-bit, and not 64-bit, which is plain "double". "float" is 32-bit.
However, note that the x86 does all floating point operations with 80-bit precision. So you don't get any performance advantage from using only single precision variables (other than lower memory bandwidth usage). Thus, a good rule of thumb is to always use double (long double might be better but isn't portable, and SSE doesn't support it if you want to use that). Single precision is mainly useful when you want to store large amounts of data (remember to cast the part of the data you're working on to double before calculating).
As others have pointed out, currently the Opteron is quite unbeatable in price/performance. 10000 EUR should certainly get you a 2 cpu system. Probably not 4 cpu:s though? Given that you need lots of memory, especially avoid the Xeon (or some other 32-bit architecture). Linux can only give 3 GB to one process with it's default configuration (I guess windows is similar?). With the so-called 4g/4g patch you can allow 4 GB for each process, but the price is lower performance. With a 64-bit architecture all those problems disappear.
Which opens a lot of questions about how that memory is managed.. Is there some sort of memory affinity per processor?
It's called a NUMA. Google for the term and ye shall find.
The memory manager of the kernel has to take NUMA into account, or performance will suck.
Not so fast, a significant problem in such a comparison is that gcc has *much* better support for x86-64 than it does for PPC64.
Well, lots of reviews trashing ppc64 sounds like a good incentive for apple to help out the gcc project then. BTW, doesn't apple use gcc as the system compiler for OS X? In that case, you can't even dismiss gcc performance as only something those dirty GNU/hippies care about.
4) A method for having sex with a computer (you know it'll happen one day... and when it does... I'm rolling in the cash)
Sorry, there is prior art: fu-fme.
Hey, don't look at me like that! I don't even use windows!
I did say petroleum. Diesel is petroleum as well.
Oops, so you did. Sorry.
It takes a tremendous amount of energy and materials to synthesize hydrocarbons.
Why should it take any more than producing hydrogen through electrolysis? Of course, today hydrogen is cheaper when produced from natural gas, but in a future when we can't use fossil fuel either because we've run out of them or due to global warming or whatever, hydrogen will have to be produced from biomass, electrolysis or some such method. Just like hydrocarbons. Given a source of hydrogen (e.g. electrolysis) and a source of carbon (e.g. biomass or some industrial process producing CO2 such as making iron or a waste incinerator) one can produce hydrocarbon fuel with e.g. Fischer-Tropsch synthesis at a quite high efficiency of about 60 %. If we imagine a future world, with clean and abundant electricity produced by fusion and solar, it is feasible to improve this efficiency to almost 100 %, save some small heat losses.
An interesting article about the problems facing an energy economy based on elemental hydrogen, as opposed to synthetic hydrocarbons, is here. I highly recommend it.
They used Fischer-Tropsch synthesis. With that, given a source of coal and a source of hydrogen, you can produce almost any kind of hydrogen chain (efficiency of course varying a lot depending on the input and the wanted output). IIRC the Nazis used coal (you know, the black thing you mine and burn, as well as the element) for coal, and water for the hydrogen source and produced gasoline. The gasoline wasn't probably up to today's standard, but technology has improved so today you can make gasoline about as good as the usual dead dino stuff we use.
Do some google searching, there is quite a lot of research going on to use Fischer-Tropsch to produce renewable fuels.
Actually, diesel has slightly higher energy density than gasoline.
Personally, I don't see any kind of hydrogen storage becoming anyway near competetive with good old hydrocarbons. In the future we'll probably drive cars that still use hydrocarbon fuels, but use fuel cells instead of internal combustion engines. And the hydrocarbon fuel will be some kind of renewable or synthetic fuel instead of dead dinosaurs.
Yeah, better to burn that petroleum. The sooner the better.
Anyway, seriously, there was a quite big study a few years ago comparing lifecycle enviromental impacts of plastic, aluminium and glass for packaging beverages. The result was inconclusive; depending on what factors you valued more (e.g. priorize raw material consumption, energy consumption, etc.) than others any of the three options would come out on top.
Banner is sooo old-fashioned:
~% apt-get install cowsay
...
~% cowsay Moo
_____
< Moo >
-----
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
this revolutioning program also includes the additional utility 'cowthink'.
Fantastic thing, this modern technology!