First, the purpose of organisms like USA's FCC goes beyond atributing slices of the electromagnetic spectrum.
Second, the problem of interference between independent systems sharing the same medium hasn't been really solved. What you have, in things like WiFi, are systems that have a finite capabiliy to co-exist with other independent systems and therefore, are allowed to be operated without a licence. But that co-existence depends on some rules and one of the tasks of organizations like FCC is to define and enforce those rules. One of those rules in particular requires attention too: maximum radiated power. Because these systems have a finite capability to co-exist without disrupting each others and because every citizen has the right to have it's own system, the rules end up putting harsh limits on the area they can cover, by restricting the maximum power they are allowed to radiate. This is the old cell phone paradigm: Need to support more clients on a given area? Reduce the power on the cells and install more cells on the area.
These legal limitations on power make systems on open spectrum unsuitable or less usefull for many aplications. For those applications, you need to give them a chunk of spectrum where they can put as much power as they need without the worry of hurting anyone else.
It was a inovative decision in terms of market strategy. But in terms of pure technology, there's nothing new about it. Actually, we'll never see much inovation in the interconnect of mass market CPUs because it's not limited by what Intel or AMD can think of and put in a chip. It's limited by how much it costs to them and specially to the technologicaly much less capable companies that build chipsets and motherbeads.
a) "burning mp3". He might meant burning audio CDs from mp3, so you have the overhead of decoding mp3.
b) some CD recorders have none or limited suport for DMA modes. That means they take a bigger piece of CPU time to handle the data transfers than you'd expect.
c) Exactly much depends on the recording mode, but the cd recording software usually has to handle quite a bit of the low level details of recording audio or data in the CDs. In particular, it may need to transform the data you have in the disk into another form suitable to be burned into a CD.
d) Recording CDs is a real-time process. With buffer underun protection less so, but things can go bad if the drive has to wait for data from the system.
That poses a problem: if one has protected data and the TPM fails, how does one recover it?
I think the answer may be in the TPM_TakeOwnership funcion. That funcion, among other things, generates a new SRK. Although it doesn't say it, could it be that the SRK is generated in a deterministic manner from the inputs? If so, that would solve the problem. But it would also mean that, for each TPM implementation, there is a SRK = f(inputs). If _f_ becomes known, that TPM implementation becomes useless for DRM.
Second option: a future Xeon and a future Itanium will be using the same chipsets -- Common System Infrastructure. Orginally, it was planned to 2007 but it might show up earlier.
There will also be a Montecito using the same FSB as Madison, so they'll be compatible with existing chipsets. That's another reason of IBM to skip it, although the current FSB is lagging performance.
Ah, I didn't get that part of your code. I'd have to add a couple of try: except: blocks to explicitly.close() the cursor and connection in case something bad happened or rely on garbage colletion to do it for me.
Python has a DB-API, but you have to import the modules. For MySQL it's MySQLdb, for PostgreSQL it's pyPgSQL.PgSQL (or a couple of others). Of course, modules being objects themselves you can play arround with as much as you like.
# I don't know Ruby but I hope I understood your code correctly..
import MySQLdb as mysql
db = mysql.connect(db="test", user="testuser", passwd="testpasswd")
cursor = db.cursor()
print "inserting..." for i in range(1,13):
songName = "Song #%d" % i
songLenght_s = str(10 * i)
cursor.execute('INSERT INTO simple01 (SongName, SongLength_s) VALUES (%(songName)s,%(songLength_s)s', vars())
print "Selecting..." cursor.execute("SELECT * FROM simple01") for row in cursor:
print row
print "Deleting" cursor.execute("DELETE FROM simple01 WHERE internal_id > 10")
There are BK->CVS and BK->SVN gateways too, for your convenience.
Well, indeed you can't have a tree that's both stable and unstable as the previous Linux kernel trees were. I just misexpressed myself. Linus liked the way things turned out for 2.6 and decided to develop it away until something disruptive enough to require a 2.7 tree shows up.
He does, it's called BitKeeper. You can download the current 2.6 kernel with: bk clone bk://linux.bkbits.net/linux-2.5
However, some people refuse to use it because it's not Free Software and has some licencing issues.
Also, Linus decided to go ahead without the previous two tree system. So, until there is any major changes requiring the split, 2.6 will be both the stable and development tree.
So, you still need point in time releases, both for users and to developers who don't want to use BitKeeper.
Actually, no. Like most other aplications of public key criptography, it uses symmetric criptography to encrypt the document with a random session key and public criptography to encrypt the session key. The most common reason is performance: symmetric chipers are much faster than public key ones. But it also allows PGP to efficently encript a document in such way it can be read by more than one person. It just includes an encripted version of the session key for each recipient.
The Top500.org list rank is based on one particular benchmark: Linpack. But Linpack is a very particular benchmark and a poor measure of system performance. In fact, it's regarded more as a pissing contest than a meaningful benchmark.
In defense of the authors of Top500.org, they didn't intended to use Linpack for ranking, they just wanted a census of the biggest machines.
They were late? As in offering one of the first lines of RISC workstations on the market is being "late" jeez! (The DECStations came out in '88, which I believe places them almost earlier than the PA-RISC, or even SPARCStations).
DECStations were introduced in 1989 and were MIPS based. Alpha wasn't introduced until 1992.
Regarding to speed, please check the results of SPEC CPU95. Compare PA-RISC and Alpha. You might be surprised.
And yes, I know x86, like other CISCs, was microcoded. I was just saying it IS a hard to decode it fast.
Random nitpicks.
* The 486 was already pipelined.
* The Pentium was already superscalar.
* What PPro really added was OoO.
* Modern x86 decoders are quite different from the old ones. They have custom logic for simpler instructions. Only more complex ones go through the microcode engine. The catch is, the ones that go to the microcode engine are much slower.
Alpha was dead at birth.
DEC was late in their change from CISC to RISC.
And when they did it, they first moved to MIPS and after MIPS they moved to Alpha.
Alpha came out with into a market already taken by other RISC cpus, with lots of ressentment towards DEC and had litte (if any) advantage over other RISC CPUs (Alpha is a cleaner ISA than other RISCs, but it doesn't provide that much of an advantage).
Thus, Alpha was allways a niche in the niche of high end RISC market, dominated by Sun, HP and IBM.
It was in the late 90's that Alpha built it's reputation for speed.
The RISC market was shrinking, being taken by Intel, and design costs were going up. Seeing that the situation would become economically unsustainable, most high end RISC's development was slowed down or just put in life support. MIPS and PA-RISC don't have a new core design in over 10 years.
IBM invested in automated chip design to cut development costs.
HP tried to figure out an ISA that would perform well on simpler chips. And then they joined to Intel and Itanium was born.
SGI and Sun just slowed down.
Alpha didn't. Maybe DEC didn't see the writing on the wall. Or maybe they tried to take advantage of others RISCs slow down.
Whatever it was, they just kept on developing it. But, despite it's performance, Alpha never gained enough market to be sustainable.
The merge with HP didn't help either. Alpha may get the headlines, but PA-RISC's customer base is much bigger.
Strangely, the x86 architecture can also be a benefit to chip design. Because x86 compresses commonly used instructions into tiny, awkward byte codes, the P4 generation of chips requires less memory and fewer cache misses - and the convoluted opcodes can be decoded quickly by the processor prior to dispatch. In the long run, Alpha's simplified instruction set proved to be less useful than machine-code x86 compatibility; and x86 chips are now little more than Alpha chips sitting behind an x86 instruction decoder. The Alpha design lives on in every CPU you buy, whether it be AMD or Intel.
Now that's crap.
* Few applications have issues with I-Cache hit rates.
* Decoding x86 is a major problem. See how many different solutions have been employed to do it since the PPro and K5.
* x86 chips are designed to the core to run x86. The fact that it breaks x86 into smaller instructions doesn't make it an Alpha beind a x86 decoder. It's like saying PPC970 is an Alpha behind a PowerPC decoder.
* Why should Alpha claim the influence of RISCs in the design of x86 CPUs? It was neither the first RISC neither the first OoO CPU.
AFAIK, the AS/400 systems were always based on pseudo-code running on a VM, instead of a real CPU ISA. A bit like Java nowadays, but the VM runs below or inside the OS (not sure), instead of on the OS. The old "AS/400" were based on some CISC CPU for which IBM never released much (if any) information while the current iSeries are based on POWERx CPUs.
However, IBM has certified a zSeries emulator for x86.
I think more than the filesystem overhead, it's the support for real AIO. AIO on files came later and I 'm pretty sure there are some Unixes that still only support it on raw devices (not counting those who don't really support AIO).
About 1: many architectures have arithmetic shifts, not just logic shifts. About 2: Are you sure about ICC8? And you're right about Java VM. In both cases, it has to do with IEEE 754 conformance, which is part of Java and C99 but not of C90, by the way.
Actually, you need -fstore-float to get those ftsp/fld pairs. And what they do is to provide results more compliant with C99/IEEE 754.
The result of -ffast-math is to turn off every bit of IEEE 754 compliance that GCC has on by default and a bit of C90 compliance (errno in log() and sqrt() that is mosty useless anyway).
AFAIK, regarding floating point, VC and ICC produce C90 compliant results except in one aspect: funcionts like log() and sqrt() don't set errno where C90 requires it. GCC is fully compliant.
However, C99 has a much more strict set of rules about results than C90, because it implements IEEE 754. But IEEE 754 compliance isn't very usefull unless the code is written to take advantage of it and it excludes lots of optimizations. I don't know of any compiler that produces compliant results by default. A first read on GCC's manual gives the idea that it does, origining lots of confusion. Actually GCC doesn't guarantee IEEE 754 compliance in any architecture. In x86, it's default behaviour is more compliant than ICC (more in regard to support for non-finite values and exceptions than precision) but to get the level of compliance that icc -mp yields, you need to dig in the documentation and use gcc -fstore-float. And according to paranoia.c, it doesn't quite get there.
First, you can contribute to Linux and Subversion. You just have to: a) not use BitKeeper b) buy a BitKeeper licence
Second, RCS doesn't support concurrent development. That's why we have CVS.
Third, why BitKeeper? Though CVS has lots of shortcommings (and thats why Subversion exists) and Subversion (SVN) is still labeled "alpha" by it's developers (though in practice it's stable enough to be self hosted and widely used), the real reason has to do with the basic model of CVS and SVN. Two main issues, in my opinion: a) In CVS/SVN you need write access to the central repository or you can't make proper use of versioning control. Giving write access is a problem for Linux's contribute based development model. BitKeeper doesn't need it. b) CVS/SVN know about branches but they don't know about merges from one branch into the other. Their view of the repository is a pure spanning tree. Subversion has a "merge" command, but a merge is commited as any other change into the repositoty. BitKeeper knows about previous merges and where they were merged from and uses that information to be smarter at resolving conflicts when you do a merge. In contribute based development every change to the project has to go through one of few maintainers who can write into the main repository (in Linux's case, there's only one), so proper merging support becomes very important. At some point before BitKeeper, Linus was having trouble keeping up with all the patches people were sending him and people were getting angry with that.
If you don't believe me, you can check the GNU Arch website: http://wiki.gnuarch.org/ They're developing a Free versioning control system very similar to BitKeeper.
I'm just speculating here, but I think the issue would be speed. CVS isn't very efficient in terms of speed or disk space. Handling something as large as the kernel might be a problem and duplicating trees with cp -rl an interesting alternative. SVN is much more efficient though. I'm not sure that comment aplied only to CVS or to avaliable versioning systems in general.
Besides the single and double precision formats, the IEEE 754 also loosely defines two classes of extented formats.
A few I know that exist: 80 bit (x87, IPF), 96 bit (Cray), 128 bit (SPARC, Alpha, PowerPC).
The thing is that, as you mentioned, to get IEEE 754 complian behaviour out of x87 you need to store and load back the results. This is because x87 only has operations on 80 bit formats, that yield results rounded to 80 bit. If you want 32 or 64 bit precision, you need to round those results to get IEEE compliant results. And the store/load cycle is the (painful) way to do it. Any IEEE 754 compliant compiler should be able to do this, its not a a GCC specific feature.
SSE/SSE2 extension and other architecures don't have this problem: they have operations that yield properly rounded results to the intended precision, no matter how they work internally.
Slashdot Mirror
First, the purpose of organisms like USA's FCC goes beyond atributing slices of the electromagnetic spectrum.
Second, the problem of interference between independent systems sharing the same medium hasn't been really solved.
What you have, in things like WiFi, are systems that have a finite capabiliy to co-exist with other independent systems and therefore, are allowed to be operated without a licence.
But that co-existence depends on some rules and one of the tasks of organizations like FCC is to define and enforce those rules.
One of those rules in particular requires attention too: maximum radiated power. Because these systems have a finite capability to co-exist without disrupting each others and because every citizen has the right to have it's own system, the rules end up putting harsh limits on the area they can cover, by restricting the maximum power they are allowed to radiate.
This is the old cell phone paradigm: Need to support more clients on a given area? Reduce the power on the cells and install more cells on the area.
These legal limitations on power make systems on open spectrum unsuitable or less usefull for many aplications. For those applications, you need to give them a chunk of spectrum where they can put as much power as they need without the worry of hurting anyone else.
It was a inovative decision in terms of market strategy. But in terms of pure technology, there's nothing new about it.
Actually, we'll never see much inovation in the interconnect of mass market CPUs because it's not limited by what Intel or AMD can think of and put in a chip. It's limited by how much it costs to them and specially to the technologicaly much less capable companies that build chipsets and motherbeads.
Multiple things.
a) "burning mp3". He might meant burning audio CDs from mp3, so you have the overhead of decoding mp3.
b) some CD recorders have none or limited suport for DMA modes. That means they take a bigger piece of CPU time to handle the data transfers than you'd expect.
c) Exactly much depends on the recording mode, but the cd recording software usually has to handle quite a bit of the low level details of recording audio or data in the CDs. In particular, it may need to transform the data you have in the disk into another form suitable to be burned into a CD.
d) Recording CDs is a real-time process. With buffer underun protection less so, but things can go bad if the drive has to wait for data from the system.
Interesting too..
o ns /F03USSCMS25_OS.pdf
http://www.intel.com/idf/us/fall2003/presentati
That poses a problem: if one has protected data and the TPM fails, how does one recover it?
I think the answer may be in the TPM_TakeOwnership funcion.
That funcion, among other things, generates a new SRK. Although it doesn't say it, could it be that the SRK is generated in a deterministic manner from the inputs? If so, that would solve the problem.
But it would also mean that, for each TPM implementation, there is a SRK = f(inputs). If _f_ becomes known, that TPM implementation becomes useless for DRM.
Second option: a future Xeon and a future Itanium will be using the same chipsets -- Common System Infrastructure.
Orginally, it was planned to 2007 but it might show up earlier.
There will also be a Montecito using the same FSB as Madison, so they'll be compatible with existing chipsets. That's another reason of IBM to skip it, although the current FSB is lagging performance.
Yes, I understood it after your other post. :)
Ah, I didn't get that part of your code. I'd have to add a couple of try: except: blocks to explicitly .close() the cursor and connection in case something bad happened or rely on garbage colletion to do it for me.
Python has a DB-API, but you have to import the modules. For MySQL it's MySQLdb, for PostgreSQL it's pyPgSQL.PgSQL (or a couple of others). Of course, modules being objects themselves you can play arround with as much as you like.
I just used Plain Old Text. But   works too.
PostgreSQL at least does.
Anyway, SQL embebbed in Python/Perl/Ruby is so simple there's nothing to gain from a SQL precompiler except static checking.
# I don't know Ruby but I hope I understood your code correctly..
import MySQLdb as mysql
db = mysql.connect(db="test", user="testuser", passwd="testpasswd")
cursor = db.cursor()
print "inserting..."
for i in range(1,13):
songName = "Song #%d" % i
songLenght_s = str(10 * i)
cursor.execute('INSERT INTO simple01 (SongName, SongLength_s) VALUES (%(songName)s,%(songLength_s)s', vars())
print "Selecting..."
cursor.execute("SELECT * FROM simple01")
for row in cursor:
print row
print "Deleting"
cursor.execute("DELETE FROM simple01 WHERE internal_id > 10")
There are BK->CVS and BK->SVN gateways too, for your convenience.
Well, indeed you can't have a tree that's both stable and unstable as the previous Linux kernel trees were. I just misexpressed myself.
Linus liked the way things turned out for 2.6 and decided to develop it away until something disruptive enough to require a 2.7 tree shows up.
He does, it's called BitKeeper.
You can download the current 2.6 kernel with:
bk clone bk://linux.bkbits.net/linux-2.5
However, some people refuse to use it because it's not Free Software and has some licencing issues.
Also, Linus decided to go ahead without the previous two tree system. So, until there is any major changes requiring the split, 2.6 will be both the stable and development tree.
So, you still need point in time releases, both for users and to developers who don't want to use BitKeeper.
Actually, no.
Like most other aplications of public key criptography, it uses symmetric criptography to encrypt the document with a random session key and public criptography to encrypt the session key.
The most common reason is performance: symmetric chipers are much faster than public key ones.
But it also allows PGP to efficently encript a document in such way it can be read by more than one person. It just includes an encripted version of the session key for each recipient.
You are right.
The Top500.org list rank is based on one particular benchmark: Linpack. But Linpack is a very particular benchmark and a poor measure of system performance. In fact, it's regarded more as a pissing contest than a meaningful benchmark.
In defense of the authors of Top500.org, they didn't intended to use Linpack for ranking, they just wanted a census of the biggest machines.
They were late? As in offering one of the first lines of RISC workstations on the market is being "late" jeez! (The DECStations came out in '88, which I believe places them almost earlier than the PA-RISC, or even SPARCStations).
DECStations were introduced in 1989 and were MIPS based. Alpha wasn't introduced until 1992.
Regarding to speed, please check the results of SPEC CPU95. Compare PA-RISC and Alpha. You might be surprised.
And yes, I know x86, like other CISCs, was microcoded. I was just saying it IS a hard to decode it fast.
Random nitpicks.
* The 486 was already pipelined.
* The Pentium was already superscalar.
* What PPro really added was OoO.
* Modern x86 decoders are quite different from the old ones. They have custom logic for simpler instructions. Only more complex ones go through the microcode engine. The catch is, the ones that go to the microcode engine are much slower.
Alpha was dead at birth.
DEC was late in their change from CISC to RISC.
And when they did it, they first moved to MIPS and after MIPS they moved to Alpha.
Alpha came out with into a market already taken by other RISC cpus, with lots of ressentment towards DEC and had litte (if any) advantage over other RISC CPUs (Alpha is a cleaner ISA than other RISCs, but it doesn't provide that much of an advantage).
Thus, Alpha was allways a niche in the niche of high end RISC market, dominated by Sun, HP and IBM.
It was in the late 90's that Alpha built it's reputation for speed.
The RISC market was shrinking, being taken by Intel, and design costs were going up. Seeing that the situation would become economically unsustainable, most high end RISC's development was slowed down or just put in life support. MIPS and PA-RISC don't have a new core design in over 10 years.
IBM invested in automated chip design to cut development costs.
HP tried to figure out an ISA that would perform well on simpler chips. And then they joined to Intel and Itanium was born.
SGI and Sun just slowed down.
Alpha didn't. Maybe DEC didn't see the writing on the wall. Or maybe they tried to take advantage of others RISCs slow down.
Whatever it was, they just kept on developing it. But, despite it's performance, Alpha never gained enough market to be sustainable.
The merge with HP didn't help either. Alpha may get the headlines, but PA-RISC's customer base is much bigger.
Strangely, the x86 architecture can also be a benefit to chip design. Because x86 compresses commonly used instructions into tiny, awkward byte codes, the P4 generation of chips requires less memory and fewer cache misses - and the convoluted opcodes can be decoded quickly by the processor prior to dispatch. In the long run, Alpha's simplified instruction set proved to be less useful than machine-code x86 compatibility; and x86 chips are now little more than Alpha chips sitting behind an x86 instruction decoder. The Alpha design lives on in every CPU you buy, whether it be AMD or Intel.
Now that's crap.
* Few applications have issues with I-Cache hit rates.
* Decoding x86 is a major problem. See how many different solutions have been employed to do it since the PPro and K5.
* x86 chips are designed to the core to run x86. The fact that it breaks x86 into smaller instructions doesn't make it an Alpha beind a x86 decoder. It's like saying PPC970 is an Alpha behind a PowerPC decoder.
* Why should Alpha claim the influence of RISCs in the design of x86 CPUs? It was neither the first RISC neither the first OoO CPU.
AFAIK, the AS/400 systems were always based on pseudo-code running on a VM, instead of a real CPU ISA. A bit like Java nowadays, but the VM runs below or inside the OS (not sure), instead of on the OS.
The old "AS/400" were based on some CISC CPU for which IBM never released much (if any) information while the current iSeries are based on POWERx CPUs.
However, IBM has certified a zSeries emulator for x86.
I think more than the filesystem overhead, it's the support for real AIO. AIO on files came later and I 'm pretty sure there are some Unixes that still only support it on raw devices (not counting those who don't really support AIO).
About 1: many architectures have arithmetic shifts, not just logic shifts.
About 2: Are you sure about ICC8? And you're right about Java VM. In both cases, it has to do with IEEE 754 conformance, which is part of Java and C99 but not of C90, by the way.
Actually, you need -fstore-float to get those ftsp/fld pairs. And what they do is to provide results more compliant with C99/IEEE 754.
The result of -ffast-math is to turn off every bit of IEEE 754 compliance that GCC has on by default and a bit of C90 compliance (errno in log() and sqrt() that is mosty useless anyway).
AFAIK, regarding floating point, VC and ICC produce C90 compliant results except in one aspect: funcionts like log() and sqrt() don't set errno where C90 requires it. GCC is fully compliant.
However, C99 has a much more strict set of rules about results than C90, because it implements IEEE 754. But IEEE 754 compliance isn't very usefull unless the code is written to take advantage of it and it excludes lots of optimizations. I don't know of any compiler that produces compliant results by default. A first read on GCC's manual gives the idea that it does, origining lots of confusion.
Actually GCC doesn't guarantee IEEE 754 compliance in any architecture. In x86, it's default behaviour is more compliant than ICC (more in regard to support for non-finite values and exceptions than precision) but to get the level of compliance that icc -mp yields, you need to dig in the documentation and use gcc -fstore-float. And according to paranoia.c, it doesn't quite get there.
First, you can contribute to Linux and Subversion. You just have to:
a) not use BitKeeper
b) buy a BitKeeper licence
Second, RCS doesn't support concurrent development. That's why we have CVS.
Third, why BitKeeper?
Though CVS has lots of shortcommings (and thats why Subversion exists) and Subversion (SVN) is still labeled "alpha" by it's developers (though in practice it's stable enough to be self hosted and widely used), the real reason has to do with the basic model of CVS and SVN. Two main issues, in my opinion:
a) In CVS/SVN you need write access to the central repository or you can't make proper use of versioning control. Giving write access is a problem for Linux's contribute based development model. BitKeeper doesn't need it.
b) CVS/SVN know about branches but they don't know about merges from one branch into the other. Their view of the repository is a pure spanning tree. Subversion has a "merge" command, but a merge is commited as any other change into the repositoty. BitKeeper knows about previous merges and where they were merged from and uses that information to be smarter at resolving conflicts when you do a merge.
In contribute based development every change to the project has to go through one of few maintainers who can write into the main repository (in Linux's case, there's only one), so proper merging support becomes very important. At some point before BitKeeper, Linus was having trouble keeping up with all the patches people were sending him and people were getting angry with that.
If you don't believe me, you can check the GNU Arch website: http://wiki.gnuarch.org/
They're developing a Free versioning control system very similar to BitKeeper.
I'm just speculating here, but I think the issue would be speed. CVS isn't very efficient in terms of speed or disk space. Handling something as large as the kernel might be a problem and duplicating trees with cp -rl an interesting alternative.
SVN is much more efficient though. I'm not sure that comment aplied only to CVS or to avaliable versioning systems in general.
Besides the single and double precision formats, the IEEE 754 also loosely defines two classes of extented formats.
A few I know that exist: 80 bit (x87, IPF), 96 bit (Cray), 128 bit (SPARC, Alpha, PowerPC).
The thing is that, as you mentioned, to get IEEE 754 complian behaviour out of x87 you need to store and load back the results. This is because x87 only has operations on 80 bit formats, that yield results rounded to 80 bit. If you want 32 or 64 bit precision, you need to round those results to get IEEE compliant results. And the store/load cycle is the (painful) way to do it. Any IEEE 754 compliant compiler should be able to do this, its not a a GCC specific feature.
SSE/SSE2 extension and other architecures don't have this problem: they have operations that yield properly rounded results to the intended precision, no matter how they work internally.