In Germany, telephone numbers are just handed out as needed, with small towns typically having shorter numbers that, say, Berlin.
This way, we simply cannot run out of numbers.
On the whole, the setup seems much more logical: dial a number (can be any length) to call within your city, dial a 0 + city code + telnumber for another city, and 00 + country code + city code + telnumber for international.>
And this is the reason why I really hate the German phone numbering system; when looking at a phonenumber you can not immediately determine if it is invalid. You have 5-digit, 6-digit, 7-digit, 8-digit, etc. numbers all within the same area code. There's no way of telling whether the number you typed in or wrote down is valid or not (ok, you might still do typos if phone numbers are of a fixed length, but most typos are by far in the form of having an additional number or missing out on one number).
In several countries (at least in Norway) all phone numbers (including numbers for mobile phones) are required to have an equal number of digits. Of course, the first few digits still provide the area code (e.g., 22 for Oslo and 776 for Tromsø) so that it makes it easier to remember phone numbers and know the location of the subscriber. You still have to type in these area codes for evey phone call, though. (As a sidenote: when Norway made typing the area code mandatory, they also removed the difference for cross area code communication so that all land-based to land-based communication is now considered "local" and priced equally. That is, there's no difference in making a phone call across the street and making it across the whole country.)
Another cool feature is directory assistance where they just SMS you the number and you dial straight from your phone (They can also connect you but that costs a lot more).
Now, according to a recent survey (can't remember the source), 13% of the SMS messages in the US were lost in the network. Any such SMS services in the US are therefore rendered more or less useless.
However, given that these are probably the German reels with the original audio track (instead of the dubbed one), all elvish will probably be subtitled in German.
Well, their web page claims that the maglev can reach 300km/h in 5 kilometers. In contrast, an ICE will need 30 kilometers to reach the same speed. I'd say that getting an average of more than 200km/h for a rail-bound track is not that easy for shorter distances.
I believe (at least in the 16bit 32bit days) a int is a machine word be it 8 16 32 64 bits.
Well, you shouldn't assume anything about the size of int. For a quick overview of the int sizes, take a look at the gcc/config/arch/arch.h files in gcc and grep for INT_TYPE_SIZE. Many architectures (IA-64, PA-RISC, SPARC, etc.) use 32 bit ints even if the word size is 64 bits.
The memory bus was twice wide on a 32bit system , so the pointers on the linked list may have been twice the size but becuase of the wider bus there was no performance hit.
Of course, chars are still 8 bits on 64-bit systems (and many applications do operate on chars). Also ints are often still 32 bits on 64 bit systems (at least that's the convention used for IA-64, use long for a 64-bit integer), and many applications do operate on ints.
You don't really have any idea of what you're talking about, do you? My experience shows that context switching between two threads is at least four times more expensive on a Pentium4 (and that's before trying to optimize the Itanium context switching code). Then there is the added benefit of having tagged TLBs on the IA-64, which removes the major performance hit when switching between address spaces/tasks on a Pentium based system.
Next, context switching from user-level to kernel-level seems to be way more inexpensive on an Itanium system compared to a Pentium 4 system. Basically, if one uses the Enter Privilege Code (EPC) instruction for doing system calls (no, Linux doesn't do this yet), there's no need to do anything exception/interruption like for entering/exiting kernel mode. This basically means that we avoid any pipeline stalls and flushes---the processor simply continues running with kernel priviliges.
If one enter the kernel due to an exception or interruption there will, however, be a bit more state which needs to be saved and restored. The large registers sets of the architecture pose almost no additional overhead here, though. The floating point registers need in general not be saved and restored on exceptions, and the register stack engine (RSE) ensures that most general purpose registers can be saved and restored lazily if needed.
In short, you seem to have no idea of what you're talking about, something which is clearly proved by your claim that running desktop environments incur a high number of context switches.
Re:No... a 64bit chip doesn't have to be 'slower'
on
AMD's 64-Bit Chip
·
· Score: 2
Problem is that the register window scheme on SPARC (and also AMD 29K) require software intervention when the CPU runs out of physical registers. The Itanium Regsiter Stack Engine (RSE), on the other hand, will spill/fill registers to/from memory automatically if it needs to. The RSE also has the ability to operate independent of the instruction stream (albeit not in the current CPU implementation). As such, the RSE is capable of utilizing free memory cycles for accessing the memory. Also, in contrast to the SPARC, the Itanium can work with other register window configurations than 8 inputs, 8 local and 8 outputs. This means a great deal if a function need only, say, 1 input register and a couple of local ones.
If I have pipes in the monitor area, most likely they would break, thos water would be going everywhere. O don't forget water on the motherboard. Well, I guess if springs a leak, I'll have to buy a new laptop.
I suppose the pipes in the monitor area are of some sort of plastic which doesn't break very easily. I also guess that instead of water one would prefer to use some sort of solution that would not cause harm to any hardware components if there should be a leak.
Get a grip. Polling always require less resources than interrupts. It's only a matter of choosing when to do the polling (i.e., when there is something to be polled). Of course, for slow devices like keyboards, polling does not really make that much sense, but the poster was talking about using polling under high network loads. Using interruptions really is costly. Not only do you have the direct cost of the interruption (stalling pipes, switching context, etc.), but interruptions can also induce indirect overhead by cache invalidations, etc. Take a look at the Soft Timers stuff for a good example of how to use polling.
Eh... how, exactly, do you manage to get from Itanium to Pentium5 by just adding some cache? I also don't get your second point; the idea of how changing to a completely new architecture (including the ISA) is comparable to simply ramping up the clock speed. I suppose you must be referring to changes between Itanium and Itanium2, but do you seriously suggest that Intel should introduce new radical changes in between generations of basically the same CPU?
Sure, you could introduce compatible stuff like HyperThreading, but I believe this is scheduled for the generation after Itanium2 (or the one after that). Nobody should really expect the Itanium2 to be much more than an incremental improvement over the Itanium. The Itanium has afterall always been regaded as sort of a developer's beta version of the architecture.
I can't imagine that the overhead is too large. As far as I can see, the intuitive way to implement this would be to generate a separate system call table for each sandboxed binary (i.e., in the same manner that you have separate syscall tables for running, e.g., emulated Linux binaries). This would impose no overhead on other executables and would for the most part not impose any overhead for the sanboxed binary either. A syscall which is unconditionally allowed simply works as usual. Other system calls like open(2) which often require a more complex test will have some overhead, though, but such open calls should not be in any time critical code anyway.
This is exactly the reason why you should choose to buy your music at your local indie record store. Buy your music from the people who stock up records from all those bands that you never knew you liked. Get your music from someone who really believes in what he/she is doing and who can broaden your horizon and enlighten you with new sounds and knowledge about the music and the musicians in general. The people behind these record stores are the good guys --- the idealists. Do try to keep these record stores open. They're probably the best means to fight the insanity.
Look at BSD and see if it includes gcc and glibc. Put your money where your mouth is and start referring to it as GNU/BSD, GNU/OpenBSD, etc. Look up every piece of GPL'ed software and start calling it GNU/. Don't forget to conveniently ignore the fact that you can use gcc to write non-free software, otherwise your point might not look as good.
Actually, the BSDs do not include glibc. Gcc is there, true, but is not required for running the system.
True. One can indeed optimize for the common case (i.e., application is waiting to receive data), and handle other cases in another manner. Just to hand the ball over to you again, though; when receiving data into a user buffer you don't want to receive packet headers, etc., into the same buffer. As such, you must have some way to split up the receive so that the headers and tailer go into one location and the packed data goes into another. This can, depending on the networking hardware, occur completely at the network card (i.e., programmable cards) or at some higher level in the OS. I don't think that one general solution to the problem exist (although I must admit that I by no means qualifies as being knowledgeable in the field).
The problem is not necessarily that of early demultiplexing of incoming packets to the appropriate ports. The problem is that in order to achieve zero-copy you'll have to store the packet at the appropriate location in memory. I.e., you must store the incoming packet in the buffer location that the user level application uses for receive. Now, obviously you can not store the packet there unless the user has requested to receive more data (the buffer may be used for other purposes). A solution to this problem is to program all the applications so that their receive buffers are aligned on page-boundaries, and the page containing the receive buffer is only used for containing the receive buffer. This allows the kernel to receive incoming data onto empty pages and map these pages into the application when the application eventually issues a receive operation.
Of course, there are more quirks to the problem than what I've discussed here. However, the point is that one can not easily implement zero-copy TCP receive without having well behaved applications (i.e., without modification of the application). Zero-copy TCP send is easier since the location of the outgoing packet is known to the kernel once the send operation starts.
sendfile() first appeared in FreeBSD3.0. This manual page first appeared in FreeBSD 3.1.
Re:Yes. Microkernel technology died last millenium
on
Hurd: H2 CD Images
·
· Score: 1
Apparently not (which answer are you referring to, by the way). I do know, however, that I am not able to prove that the documents in question do not exist. You, on the other hand, is in the position that it should be relatively easy to disprove me. Just show me the documents and I'll be happy to announce that you were right in the first place.
Re:Yes. Microkernel technology died last millenium
on
Hurd: H2 CD Images
·
· Score: 1
I repeat: URLs? Order Numbers?
Re:Yes. Microkernel technology died last millenium
on
Hurd: H2 CD Images
·
· Score: 1
URLs? Order Numbers? I know of no documents on the Intel site answering the questions of my previous posts. You obviously seem to do, but I guess you never actually bothered to find out what the documentation provided there really is.
Re:Yes. Microkernel technology died last millenium
on
Hurd: H2 CD Images
·
· Score: 1
Again, reading (and understanding) the doc (not just the specs) is required to really do efficient kernel programming.
Slashdot Mirror
Much of what you describe here is already part of ID3v2.
In several countries (at least in Norway) all phone numbers (including numbers for mobile phones) are required to have an equal number of digits. Of course, the first few digits still provide the area code (e.g., 22 for Oslo and 776 for Tromsø) so that it makes it easier to remember phone numbers and know the location of the subscriber. You still have to type in these area codes for evey phone call, though. (As a sidenote: when Norway made typing the area code mandatory, they also removed the difference for cross area code communication so that all land-based to land-based communication is now considered "local" and priced equally. That is, there's no difference in making a phone call across the street and making it across the whole country.)
Now, according to a recent survey (can't remember the source), 13% of the SMS messages in the US were lost in the network. Any such SMS services in the US are therefore rendered more or less useless.
However, given that these are probably the German reels with the original audio track (instead of the dubbed one), all elvish will probably be subtitled in German.
Well, their web page claims that the maglev can reach 300km/h in 5 kilometers. In contrast, an ICE will need 30 kilometers to reach the same speed. I'd say that getting an average of more than 200km/h for a rail-bound track is not that easy for shorter distances.
This has been tried (albeit not using Linux). It's called Mach, and is by many people considered somewhat of a failure.
Well, you shouldn't assume anything about the size of int. For a quick overview of the int sizes, take a look at the gcc/config/arch/arch.h files in gcc and grep for INT_TYPE_SIZE. Many architectures (IA-64, PA-RISC, SPARC, etc.) use 32 bit ints even if the word size is 64 bits.
Of course, chars are still 8 bits on 64-bit systems (and many applications do operate on chars). Also ints are often still 32 bits on 64 bit systems (at least that's the convention used for IA-64, use long for a 64-bit integer), and many applications do operate on ints.
No, sorry. I haven't worked with these systems, so I can not really tell how well/bad they perform in this context.
Next, context switching from user-level to kernel-level seems to be way more inexpensive on an Itanium system compared to a Pentium 4 system. Basically, if one uses the Enter Privilege Code (EPC) instruction for doing system calls (no, Linux doesn't do this yet), there's no need to do anything exception/interruption like for entering/exiting kernel mode. This basically means that we avoid any pipeline stalls and flushes---the processor simply continues running with kernel priviliges.
If one enter the kernel due to an exception or interruption there will, however, be a bit more state which needs to be saved and restored. The large registers sets of the architecture pose almost no additional overhead here, though. The floating point registers need in general not be saved and restored on exceptions, and the register stack engine (RSE) ensures that most general purpose registers can be saved and restored lazily if needed.
In short, you seem to have no idea of what you're talking about, something which is clearly proved by your claim that running desktop environments incur a high number of context switches.
Problem is that the register window scheme on SPARC (and also AMD 29K) require software intervention when the CPU runs out of physical registers. The Itanium Regsiter Stack Engine (RSE), on the other hand, will spill/fill registers to/from memory automatically if it needs to. The RSE also has the ability to operate independent of the instruction stream (albeit not in the current CPU implementation). As such, the RSE is capable of utilizing free memory cycles for accessing the memory. Also, in contrast to the SPARC, the Itanium can work with other register window configurations than 8 inputs, 8 local and 8 outputs. This means a great deal if a function need only, say, 1 input register and a couple of local ones.
I suppose the pipes in the monitor area are of some sort of plastic which doesn't break very easily. I also guess that instead of water one would prefer to use some sort of solution that would not cause harm to any hardware components if there should be a leak.
Get a grip. Polling always require less resources than interrupts. It's only a matter of choosing when to do the polling (i.e., when there is something to be polled). Of course, for slow devices like keyboards, polling does not really make that much sense, but the poster was talking about using polling under high network loads. Using interruptions really is costly. Not only do you have the direct cost of the interruption (stalling pipes, switching context, etc.), but interruptions can also induce indirect overhead by cache invalidations, etc. Take a look at the Soft Timers stuff for a good example of how to use polling.
Sure, you could introduce compatible stuff like HyperThreading, but I believe this is scheduled for the generation after Itanium2 (or the one after that). Nobody should really expect the Itanium2 to be much more than an incremental improvement over the Itanium. The Itanium has afterall always been regaded as sort of a developer's beta version of the architecture.
I can't imagine that the overhead is too large. As far as I can see, the intuitive way to implement this would be to generate a separate system call table for each sandboxed binary (i.e., in the same manner that you have separate syscall tables for running, e.g., emulated Linux binaries). This would impose no overhead on other executables and would for the most part not impose any overhead for the sanboxed binary either. A syscall which is unconditionally allowed simply works as usual. Other system calls like open(2) which often require a more complex test will have some overhead, though, but such open calls should not be in any time critical code anyway.
This is exactly the reason why you should choose to buy your music at your local indie record store. Buy your music from the people who stock up records from all those bands that you never knew you liked. Get your music from someone who really believes in what he/she is doing and who can broaden your horizon and enlighten you with new sounds and knowledge about the music and the musicians in general. The people behind these record stores are the good guys --- the idealists. Do try to keep these record stores open. They're probably the best means to fight the insanity.
True. I never knew until I accidentaly right clicked the mouse and moved it slightly left. After that incident I am not able to browse without them.
Actually, the BSDs do not include glibc. Gcc is there, true, but is not required for running the system.
True. One can indeed optimize for the common case (i.e., application is waiting to receive data), and handle other cases in another manner. Just to hand the ball over to you again, though; when receiving data into a user buffer you don't want to receive packet headers, etc., into the same buffer. As such, you must have some way to split up the receive so that the headers and tailer go into one location and the packed data goes into another. This can, depending on the networking hardware, occur completely at the network card (i.e., programmable cards) or at some higher level in the OS. I don't think that one general solution to the problem exist (although I must admit that I by no means qualifies as being knowledgeable in the field).
Of course, there are more quirks to the problem than what I've discussed here. However, the point is that one can not easily implement zero-copy TCP receive without having well behaved applications (i.e., without modification of the application). Zero-copy TCP send is easier since the location of the outgoing packet is known to the kernel once the send operation starts.
HISTORY
Apparently not (which answer are you referring to, by the way). I do know, however, that I am not able to prove that the documents in question do not exist. You, on the other hand, is in the position that it should be relatively easy to disprove me. Just show me the documents and I'll be happy to announce that you were right in the first place.
I repeat: URLs? Order Numbers?
URLs? Order Numbers? I know of no documents on the Intel site answering the questions of my previous posts. You obviously seem to do, but I guess you never actually bothered to find out what the documentation provided there really is.
URLs? Order numbers?