The SPARC T1 would probably not be very good for 3D graphics and other calculations in a game, because it only has 1 FPU. Of course it could have a good 3D graphics card, but then what are you using the processor for? The T1 is really optimized for an application server or something like that.
If you're filling out your info in order to use software, you might expect it to not be sent out. That's almost like personalizing the software, and possibly registering it at the end. Notice that MS Word does not ask you any political questions, because that would have nothing to do with using the software (at least, not yet).
However, if you're just filling out a form to fill out a form, it's pretty unreasonable to expect that the information stay on your computer.
Before entering personal data anywhere you should have some kind of awareness how it will be used. Entering the data alone is a certain amount of implied consent. If the software harvests the data, even from itself, I'd see your point. But the people are actually entering their data and opinions.
Now, public on a website is a different matter. That should probably be disclosed out of ethics, but I guess if you don't ask any questions ahead of time, it could be sent to many other companies anyway.
There is no magic silver bullet to vectorizing code.
It's even harder when there's no memory protection. One might imagine (within reason) that a Java compiler could separate independent tasks by tracking what variables are used in what sections of code, and inferring that one section must be independent of another until you reach line X (at which point you may need to synchonize access to a variable the two pieces have in common, or join the threads). That could (perhaps) achieve decent multithreaded performance even for apps written in sequential code.
However, if there's no memory protection, then any pointer in the code can affect any other part of the running code (except for, e.g., a memory page in the text segment which may be hardware protected), because it's all running in the same virtual address space. So it makes me wonder how they even begin to attack that problem from the compiler. Of course adding support to the language like you suggest makes it easier for the programmer to do it, but the article is talking about the compiler doing it for the programmer.
The cell looks like it has a real chance of becoming the next big advancement.
It will be interesting to compare the Cell with the UltraSPARC T1 (Niagara). They both have about 8 cores (T1 is 8 cores, Cell is 8+1), but the T1 can do 32 threads of execution simultaneously. The Cell has good floating point performance, but the T1 only has 1 FPU for all 8 cores (it's specifically not designed for FP performance). The T1 has very low power requirements, at about 72 watts (79 peak), while (as far as I can tell from google) the Cell will have high power consumption and they have not disclosed the exact figures yet.
And both companies are working very closely with the open source community. Sun actually went further, and open sourced the entire SPARC architecture. As far as I know, IBM is not opening up their architecture.
They clearly have different markets, but they are similar in the multithreading aspect. Whoever does a better job of the multithreading and makes good compilers that can help the programmers write parallel code will then be able to move into the other company's space (if Sun does it better, they can add FPUs, if IBM does better they can remove them). And that success depends on open source involvement, which depends on an architecture that is easy to code for. If open source programmers get heavily involved in a concurrent compiler for one architecture, it will win in the long term.
So, it's clear why both companies are fighting to get the attention of the open source community, which is becoming (in a lot of ways) the force that drives which technologies are actually used in business. And that's certainly good news.
In this specific case, the Sun Niagra Servers are high power, high throughput machines, tasked better for a mega dollar installation where speed is critical, or in your business where uptime seems to be the more desired feature.
From what I read, these servers are only $5k. That's not in the super-cheap realm, but it's not expensive either. These servers are also supposed to get a lot more throughput, meaning that maybe the combined processing power of 10 cheap systems in a cluster might be less than 1 Niagara. You avoid all the clustering overhead, and every thread of execution (32 threads at once on one chip!) has local access to all the memory (unlike a cluster, where the memory is broken up and needs to be sent over the network for processing).
If this chip is what they say it is, it's going to target everyone who wants good price/performance.
From the processor's perspective, how is a parallelized workload different than autonomous threads? How are they different at all, except for the points in a parallel workload that require communication between the threads?
They've thought long and hard about common workloads, and have come up with a CPU optimised for those workloads
In order for this chip to take over the world, it needs to push developers to parallelize their applications more. That's a good possibility, since every chipmaker is moving toward multiple cores, etc., and so developers need to change their ways eventually. If this chip is what Sun says it is, it may give developers that real push into parallel applications.
In 5 years, it's possible that making everything parallel will be a basic principle just like making modular code.
Perhaps that's the reason that they are innovating. If this processor is what they say it is (and SPEC seems to indicate that it is), they will be the only ones to go to for this type of performance. And most likely, for similar performance, it will be way cheaper and more reliable then trying to throw together a cluster of cheap machines.
I'm sure we'll know once the numbers come out. If they really have done something powerful, their profits will return.
They have many companies behind them. And that development organization has been maturing over a long period of time to get where it is today.
You can't dump the source to MySQL, InnoDB, and BDB out into the wild and expect the quality development you get from the PostgreSQL community overnight. It takes years. Companies slowly sign on as they see progress, and have conflicting goals for the project. You need coordinated documentation people, release people, general organizers, community advocates, active mailing lists, active IRC, dispute resolvers, testers, and coders. It's a sophisticated social organization, and it takes a long time for everyone to find their place.
The markets for Oracle and MySQL, though, basically don't overlap at all.
So, you must think that Oracle saw huge profits on the horizon for all of MySQL AB, Innobase, and Sleepycat, and wanted to buy them as a strategic investment?
Or maybe Oracle needed their technology, because it didn't have enough database technology already?
I can't help but think the disk i/o would really be the only factor. Perhaps you can provide a link so I can guess if there are any other factors involved.
Anything can read some records from a disk. Even if you index it, it's not like the indexing schemes are that much different between databases. If MySQL was much slower than the disk I would think it was doing something wrong.
Or if it embeds the client library, which most software that uses MySQL needs to do directly or indirectly.
You can talk about using an abstraction layer like JDBC, but if you're doing that just to circumvent the "derivitive work" definition I'm not sure that would stand up in court.
Solaris is free, and you can run MySQL/PostgreSQL on top with no problem. I just wanted to clarify that you could have left the Solaris->Linux swap out of your equation, because that doesn't have anything to do with cost.
However, the question remains: who? MySQL's development is currently centralized at MySQL AB. That makes it harder for other developers to pick it up and run with it. There are probably not many people who know the MySQL internals except for the MySQL AB employees.
It, of course, takes time to learn, and that time is what Oracle is buying.
Other projects like PostgreSQL already have a distributed community of developers and has more history taking outside contributions. So it's a little less vulnerable.
I'll have a BS in EE from UC San Diego this June. My "depth" was in software systems. Took one database class, got an A and a letter of recommendation. I took every class required for a CE major except compilers. Independently read "An Introduction to Database Systems" out of interest, and followed it up with the 3rd manifesto, also by C.J. Date. I'm looking for a job in California starting a few weeks after graduation.
Although, the acronym still doesn't work all that well. Many serious postgresql users use a platform other than Linux. FreeBSD as well as a lot of the other UNIXes are popular. I believe one of the developers actually prefers HPUX. There must be some kind of reason, but I don't know what it is.
Where are you getting your information? PostgreSQL is very stable, and if you want to argue otherwise you need evidence.
PostgreSQL is less vulernable because the developers all work for different companies. Some of those companies are very large. At least one of those companies is much larger than Oracle (Fujitsu).
And it IS on Oracle's radar. It has been at least since Oracle fought the assignment of the.ORG or.INFO registry to Afilias, and lost (Afilias runs those registries from PostgreSQL).
PostgreSQL may not be on every web hosting ad you see, but don't let that fool you.
Out of all the databases, MySQL's dialect of SQL seems the most different to me. It's common for coders to use the "`" character (backtick) as some kind of identifier string delimiter or something. I really don't think that's in the SQL spec. And the semantics are different also... particularly the handling of NULLs and out-of-bounds values.
So, that makes it more difficult to be database agnostic. If you have an application that uses that kind of SQL, MySQL AB could make a reasonable argument that you're just using JDBC to circumvent the definition of "derivitive work", and could sue. I don't know whether that claim has merit in court or not, but it seems like a reasonable claim to make.
If people would adhere to standards, it wouldn't be a problem. I agree that things like JDBC are a good idea. If features are shared between two databases, you shouldn't need two different ways to access that feature. If you use a unique feature, at least it will be only one thing you have to port rather than everything.
I was saying that more as a hypothetical. Obviously none of those 3 things are going to happen any time soon, which is why I think MySQL will have some serious problems.
You are correct. Making a non-GPL client library would effectively be stabbing MySQL AB in the back, and eleiminating their primary source of revenue.
They could. After all, PostgreSQL is BSD licensed, so it's easy from a licensing standpoint.
However, the obvious question is why not take PostgreSQL's front end also, and just get it from www.postgresql.org? If MySQL uses PostgreSQL as an engine, eventually people are just going to go straight to PostgreSQL and cut out the middle man.
What if Oracle reassigns the developers of those backends to other projects? Now who develops those backends? Open source coders, you're right. But the open source developers won't act as a successful organization for years. In the meantime, Oracle has essentially bought a couple years' delay, which may effectively kill those backends.
And also, consider that you can't link the client libraries with anything other than GPL code. If you have an open source project that's not GPL, you can't add MySQL support.
Open source works in the long term. I'm talking about the next few years.
Slashdot Mirror
The SPARC T1 would probably not be very good for 3D graphics and other calculations in a game, because it only has 1 FPU. Of course it could have a good 3D graphics card, but then what are you using the processor for? The T1 is really optimized for an application server or something like that.
If you're filling out your info in order to use software, you might expect it to not be sent out. That's almost like personalizing the software, and possibly registering it at the end. Notice that MS Word does not ask you any political questions, because that would have nothing to do with using the software (at least, not yet).
However, if you're just filling out a form to fill out a form, it's pretty unreasonable to expect that the information stay on your computer.
Before entering personal data anywhere you should have some kind of awareness how it will be used. Entering the data alone is a certain amount of implied consent. If the software harvests the data, even from itself, I'd see your point. But the people are actually entering their data and opinions.
Now, public on a website is a different matter. That should probably be disclosed out of ethics, but I guess if you don't ask any questions ahead of time, it could be sent to many other companies anyway.
There is no magic silver bullet to vectorizing code.
It's even harder when there's no memory protection. One might imagine (within reason) that a Java compiler could separate independent tasks by tracking what variables are used in what sections of code, and inferring that one section must be independent of another until you reach line X (at which point you may need to synchonize access to a variable the two pieces have in common, or join the threads). That could (perhaps) achieve decent multithreaded performance even for apps written in sequential code.
However, if there's no memory protection, then any pointer in the code can affect any other part of the running code (except for, e.g., a memory page in the text segment which may be hardware protected), because it's all running in the same virtual address space. So it makes me wonder how they even begin to attack that problem from the compiler. Of course adding support to the language like you suggest makes it easier for the programmer to do it, but the article is talking about the compiler doing it for the programmer.
The cell looks like it has a real chance of becoming the next big advancement.
It will be interesting to compare the Cell with the UltraSPARC T1 (Niagara). They both have about 8 cores (T1 is 8 cores, Cell is 8+1), but the T1 can do 32 threads of execution simultaneously. The Cell has good floating point performance, but the T1 only has 1 FPU for all 8 cores (it's specifically not designed for FP performance). The T1 has very low power requirements, at about 72 watts (79 peak), while (as far as I can tell from google) the Cell will have high power consumption and they have not disclosed the exact figures yet.
And both companies are working very closely with the open source community. Sun actually went further, and open sourced the entire SPARC architecture. As far as I know, IBM is not opening up their architecture.
They clearly have different markets, but they are similar in the multithreading aspect. Whoever does a better job of the multithreading and makes good compilers that can help the programmers write parallel code will then be able to move into the other company's space (if Sun does it better, they can add FPUs, if IBM does better they can remove them). And that success depends on open source involvement, which depends on an architecture that is easy to code for. If open source programmers get heavily involved in a concurrent compiler for one architecture, it will win in the long term.
So, it's clear why both companies are fighting to get the attention of the open source community, which is becoming (in a lot of ways) the force that drives which technologies are actually used in business. And that's certainly good news.
In this specific case, the Sun Niagra Servers are high power, high throughput machines, tasked better for a mega dollar installation where speed is critical, or in your business where uptime seems to be the more desired feature.
From what I read, these servers are only $5k. That's not in the super-cheap realm, but it's not expensive either. These servers are also supposed to get a lot more throughput, meaning that maybe the combined processing power of 10 cheap systems in a cluster might be less than 1 Niagara. You avoid all the clustering overhead, and every thread of execution (32 threads at once on one chip!) has local access to all the memory (unlike a cluster, where the memory is broken up and needs to be sent over the network for processing).
If this chip is what they say it is, it's going to target everyone who wants good price/performance.
From the processor's perspective, how is a parallelized workload different than autonomous threads? How are they different at all, except for the points in a parallel workload that require communication between the threads?
They've thought long and hard about common workloads, and have come up with a CPU optimised for those workloads
In order for this chip to take over the world, it needs to push developers to parallelize their applications more. That's a good possibility, since every chipmaker is moving toward multiple cores, etc., and so developers need to change their ways eventually. If this chip is what Sun says it is, it may give developers that real push into parallel applications.
In 5 years, it's possible that making everything parallel will be a basic principle just like making modular code.
Perhaps that's the reason that they are innovating. If this processor is what they say it is (and SPEC seems to indicate that it is), they will be the only ones to go to for this type of performance. And most likely, for similar performance, it will be way cheaper and more reliable then trying to throw together a cluster of cheap machines.
I'm sure we'll know once the numbers come out. If they really have done something powerful, their profits will return.
To a certain extent that's true, but it's harder.
One problem for Oracle would be that anyone in the world who wants a job at Oracle could just hack at PostgreSQL for a couple months.
They have many companies behind them. And that development organization has been maturing over a long period of time to get where it is today.
You can't dump the source to MySQL, InnoDB, and BDB out into the wild and expect the quality development you get from the PostgreSQL community overnight. It takes years. Companies slowly sign on as they see progress, and have conflicting goals for the project. You need coordinated documentation people, release people, general organizers, community advocates, active mailing lists, active IRC, dispute resolvers, testers, and coders. It's a sophisticated social organization, and it takes a long time for everyone to find their place.
The markets for Oracle and MySQL, though, basically don't overlap at all.
So, you must think that Oracle saw huge profits on the horizon for all of MySQL AB, Innobase, and Sleepycat, and wanted to buy them as a strategic investment?
Or maybe Oracle needed their technology, because it didn't have enough database technology already?
I can't help but think the disk i/o would really be the only factor. Perhaps you can provide a link so I can guess if there are any other factors involved.
Anything can read some records from a disk. Even if you index it, it's not like the indexing schemes are that much different between databases. If MySQL was much slower than the disk I would think it was doing something wrong.
If your software embeddeds a MySQL database
Or if it embeds the client library, which most software that uses MySQL needs to do directly or indirectly.
You can talk about using an abstraction layer like JDBC, but if you're doing that just to circumvent the "derivitive work" definition I'm not sure that would stand up in court.
Please email me your email address at j3davis [at] ucsd (dot) edu, and I'll be happy to send you my resume.
Solaris is free, and you can run MySQL/PostgreSQL on top with no problem. I just wanted to clarify that you could have left the Solaris->Linux swap out of your equation, because that doesn't have anything to do with cost.
But can they fork the InnoDB stuff?
Yup, sure can. It's GPL too.
However, the question remains: who? MySQL's development is currently centralized at MySQL AB. That makes it harder for other developers to pick it up and run with it. There are probably not many people who know the MySQL internals except for the MySQL AB employees.
It, of course, takes time to learn, and that time is what Oracle is buying.
Other projects like PostgreSQL already have a distributed community of developers and has more history taking outside contributions. So it's a little less vulnerable.
I'll have a BS in EE from UC San Diego this June. My "depth" was in software systems. Took one database class, got an A and a letter of recommendation. I took every class required for a CE major except compilers. Independently read "An Introduction to Database Systems" out of interest, and followed it up with the 3rd manifesto, also by C.J. Date. I'm looking for a job in California starting a few weeks after graduation.
Yeah, that was creative :)
Although, the acronym still doesn't work all that well. Many serious postgresql users use a platform other than Linux. FreeBSD as well as a lot of the other UNIXes are popular. I believe one of the developers actually prefers HPUX. There must be some kind of reason, but I don't know what it is.
You don't think it's a coincidence that Oracle bought the only two open source transactional backends available for MySQL?
Where are you getting your information? PostgreSQL is very stable, and if you want to argue otherwise you need evidence.
.ORG or .INFO registry to Afilias, and lost (Afilias runs those registries from PostgreSQL).
PostgreSQL is less vulernable because the developers all work for different companies. Some of those companies are very large. At least one of those companies is much larger than Oracle (Fujitsu).
And it IS on Oracle's radar. It has been at least since Oracle fought the assignment of the
PostgreSQL may not be on every web hosting ad you see, but don't let that fool you.
Out of all the databases, MySQL's dialect of SQL seems the most different to me. It's common for coders to use the "`" character (backtick) as some kind of identifier string delimiter or something. I really don't think that's in the SQL spec. And the semantics are different also... particularly the handling of NULLs and out-of-bounds values.
So, that makes it more difficult to be database agnostic. If you have an application that uses that kind of SQL, MySQL AB could make a reasonable argument that you're just using JDBC to circumvent the definition of "derivitive work", and could sue. I don't know whether that claim has merit in court or not, but it seems like a reasonable claim to make.
If people would adhere to standards, it wouldn't be a problem. I agree that things like JDBC are a good idea. If features are shared between two databases, you shouldn't need two different ways to access that feature. If you use a unique feature, at least it will be only one thing you have to port rather than everything.
I was saying that more as a hypothetical. Obviously none of those 3 things are going to happen any time soon, which is why I think MySQL will have some serious problems.
You are correct. Making a non-GPL client library would effectively be stabbing MySQL AB in the back, and eleiminating their primary source of revenue.
It's much easier to just use PostgreSQL.
They could. After all, PostgreSQL is BSD licensed, so it's easy from a licensing standpoint.
However, the obvious question is why not take PostgreSQL's front end also, and just get it from www.postgresql.org? If MySQL uses PostgreSQL as an engine, eventually people are just going to go straight to PostgreSQL and cut out the middle man.
What if Oracle reassigns the developers of those backends to other projects? Now who develops those backends? Open source coders, you're right. But the open source developers won't act as a successful organization for years. In the meantime, Oracle has essentially bought a couple years' delay, which may effectively kill those backends.
And also, consider that you can't link the client libraries with anything other than GPL code. If you have an open source project that's not GPL, you can't add MySQL support.
Open source works in the long term. I'm talking about the next few years.
I think what you're saying is at least in the spirit of the GPL, so I'll just concede this point until I'm more informed.