This includes not only the OS's operation, but even 32bit applications running on the OS.
My understanding is that 32bit application would run slightly slower if the CPU was in 64bit mode. Presumably 15% would be the overall system performance, including legacy 32-bit applications?
You see when you have a 64bit memory addressing and can optimize for this in the memory manager you no longer have FS and pagefile lookkup tables for extended amounts of RAM.
What is a FS (filesystem?) lookup table?
You also can do like Vista x64 does and shove two 32bit memory writes into on 64bit address space, so when it can, you get double the read/write performance out of the memory chip because you are pulling two 32bit chunks in one read cycle.
By "64 bit address space" I presume you mean 64 bit register (you fit 2^32 32bit address spaces in a 64bit address space). But even in 32bit mode Intel CPUs can access 128bit registers via SSE. Anyway, this presumably has more to do with your compiler than your OS, so I don't know what Vista has to do with this.
Everything else being equal, 64bit software would run slower than 32 bit, because you need twice as many bits to represent a pointer. Essentially, unless you need an address space larger than 4GB, you are wasting 32bits on every pointer. This would waste memory, cache and memory bandwidth etc. The standard answer as to why 64bit software runs faster on Intel/AMD CPUs is that on these CPUs everything else is *not* equal.
The biggest bonus to running in 64bit mode on Intel/AMD chips is that since 64bit is essentially a whole new arch, we can throw out all the backward compatibility. In 64bit mode we actually have a decent number of registers. Also since 64bit code won't run on old processors anyway, there is no point in compiling code to be backward compatible with the old i586.
Understand yet?
Not really. Not any better than I understand this paper anyway:P. Could you give links explaining your claims above?
Well, at the moment we don't really have the command line as a failsafe. When the X server crashes it seems to lock up the keyboard so Cntl-Alt-F1 doesn't switch to the VT (though I can usually ssh in, and restart X, but then I could also ssh -Y and restart X with a remote GUI, so the "commandline" doesn't really help here).
Its similar to how having a database server tends to be more reliable than having clients directly accessing the database files. Yes, the database server adds a single point of failure, but that is better than having 20+ nodes each of which can horribly corrupt the database files. While in principle GEM could fail, so could the hundred other modules in my kernel. And a bug in GEM is unlikely to be as serious as a bug in ext3/4.
I mainly used it for Maple V. When I had an nVidia card I also used it to play Team Fortress II with my windows friends.
One thing to consider: the applications you describe run fine in any virtualization software, where as 3D games do not. Even if your virtualization software supports 3D it might have a very heavy overhead. Apparently Hardware Lighting is 87% slower in Parallels 3. Thus it is reasonable that getting popular 3D intensive applications to run in Wine is a priority.
Also note that CrossOver Office is based on Wine, and that some software producers officially support Wine (e.g. Google supports running Picasa under wine). So, despite its problems I still like Wine... I also like Wine Is Not an Emulator;)
I don't know what you mean by "Relax on APIs". However WineLibs makes porting applications to Linux much easier. Wine is Not an Emulator, it is a reimplementation of the Win32 libraries. This means that it need not be slower, and even though Wine is not fully optimized it is already faster than Windows XP in some areas. If your app doesn't just instantly work in Wine then you have found a bug in Wine*, you just have to fix or workaround that bug. Otherwise you'd have to change every part of your program.
* or you have found a buffer overrun that just happens not to be detected by Windows. Congratulations. Also tweaking the GUI a bit would help so it would fit in better, but not strictly speaking essential
Also, I imagine that Asus paid far less for the 4GB SSD on the Eeepc 701 than they would have paid for any harddisk. The claim that hdds are cheaper is presumably per GB rather than per device which is perfectly capable of standard tasks such as word processing.
Although it is less than 20% of the total footprint of life-cycle of the car. I understand that refining the metal to make the batteries is fairly polluting. However it is very easy to recycle the metal, and since the metal is reasonably valuable there is a significant financial incentive to do so. I am not sure how much the metal is worth but Toyota pays $200 for hybrid batteries (Toyota may be subsiding this so the actual metal is worth less).
Zip! Nada! In fact when they send packets over my network connection they pay a *negative* amount! If you want to find the real bandwidth hogs, it is the Telcos.
All those people who browse http://localhost/ at ridiculous speeds without paying a cent are pretty greedy too.
... Back in the real world there is central node called "The Internet" that has to route all traffic. If you want to connect to someones network they may ask for money, if they want to connect to your network, you can ask them for money. How much money is up to you and them.
The smaller the stack size, the easier it is to allocate memory for the stack, but also the harder it is to write drivers etc. that don't overrun the stack.
Most allocations in a paging system are done by page. A 8k stack on x86 means that you need to find two adjacent free pages, finding two adjacent pages can be difficult. A 4K stack means that you only need to find one page, i.e. so long as there are pages free you can easily allocate a 4K stack. Thus there is little benefit to having a stack smaller than 4K, having a 1K stack would save a small amount of memory, but wouldn't make it any faster to allocate a new stack.
The lower limit on Fragmentation? Not really. If you have a hundred more mallocs than frees, you'll have to track one hundred mallocs and perhaps another hundred chunks of free space. A smarter algorithm can use clever heuristics to avoid some fragmentation at the cost of performance, but if anything this would usually result in less chunks of free space. At the end of the day no matter how smart the algorithm or how many chunks it manages, if you allocate memory in 32bytes chunks and then free all but one 32 byte chunk from each 4K page, you'll end up with 99% fragmentation.
I don't know about BSD, but Linux now uses the 2Q allocator. This means that the cache will be released shortly, unless it is accessed a second time. This should prevent updatedb etc. from forcing out all other pages out of RAM by trying to cache the entire contents of the harddisk.
If you have a single 32 byte fragment in a 4KB page, you cannot release the page back to the OS. If you can reduce memory fragmentation by 1% you reduce the amount of memory you need to request from the OS by 1%. There is still work being done on allocators that minimize fragmentation. It is not clear how you can defragment memory after it has been allocated though. It would be very hard to safely update the pointers in a C program to point to the new memory locations after defragmentation. Possibly these memory defragmenters move around pages of virtual memory so that the kernel can allocate 8KB and larger chunks of physical memory (Kernels typically bypass VM and prefer pages that are physically adjacent). I understand that the motivation for the 4K stacks in the Linux Kernel was the difficulty in finding two adjacent free physical pages. This would be even more of an issue on Windows which apparently use 12K stacks.
Assuming 1400 byte max packet data, 8 bytes of file position (i.e. files may be bigger than 4GiB), 4 bytes to give the index of a file, that's 1388 byte packets... 3094357 packets at least for 4GB, an extra 32MB.
Note that UDP packets are 12 bytes smaller than TCP, so we are already breaking even. Since we control the protocol, we could e.g. download files in 4GB chunks so that we could use an 4 bytes of file position. In principle we could also have the source IP and port number uniquely identify the file, and thus eliminate the the file index from the packet. Then we are saving 8 bytes per packet by using UDP.
Even the latest EeePC models still come with XP (or Linux). Windows Business licenses allow installation of XP, and you still get the occasional non-netbook machine with XP pre-installed. However from the summary itself, if you really want to stay with XP, one option is just to buy a *used* XP machine. There are people still running Mac Classics out there.
Here is a link that discusses this further. They mention that a human can see an object that is displayed for one 500th of a second, if it is bright enough. In RL your eyes do the motion blur for you. This is also similar to how anti-aliasing works, which in its basic form is rending the frames at a higher resolution than the monitor can display and then downsizing the picture so we can averaging the pixels.
I think your example is rather extreme. First of all, if the aeroplane didn't crash the claim would be obviously false. If the aeroplane did crash the there would be huge inquiry, the engineer/aggressor who decided to misuse the OS code in a place would also bear liability and would be in a world of pain. If so much as a hint got out that they intentionally crashed the plane then they would be charged with a hundred counts of homicide... and thats if they are lucky enough not be a tried under anti-terrorist law.
The realistic outcome would be that someone yanks the code out of somewhere, doesn't bother to check it, and decides to sue someone. IANAL, (and I am certainly not a lawyer in every jurisdiction of the world) but the common wisdom is that even when suing a company you've paid for software the courts have held that it is the buyers responsibility to check suitability, not the producer of commodity software.
Well yes but, it is never the bug you are expecting that bites you in the final release (was it a final release? it was RC29). It is always the bug that is so mindbogglingly stupid that you never think to check for it.
I don't *think* it much of a "security" flaw, as you say; but you don't want random command being run as root with random arguments. Who knows what would happen? Infact administrators often spend most of their time logged in as a non-root users so they don't accidentally do stupid things. Having every thing you type run as a root command is badly broken.
It'd be really annoying just having the system reboot whenever I tell someone to
They also have a Slashdot account. That is fairly easy to use.
The obvious way is to pick some random unrelated software project and threaten to use windows unless they rewrite it to be a medical app. This is the number one n00b mistake. You will be quickly identified as a troll and hounded off Slashdot.
Instead continually praise the unrelated app as being the best biomedical confubulator ever written. Then you'll have thousands of users attempting to use it as a biomedical confubulator getting angry and threatening to switch to windows for you.
The best thing about this technique is that the Slashdot hive mind will never catch on, and in fact everybody who contradicts you by saying that your victim project can't do medical confubulations, *they* will be labeled as a troll and hounded off Slashdot. The technique is infallible I tell you;)
Slashdot Mirror
full 64bit drivers that can shove data to devices oh like Video cards much faster
How do 64bit drivers speed up DMA?
This includes not only the OS's operation, but even 32bit applications running on the OS.
My understanding is that 32bit application would run slightly slower if the CPU was in 64bit mode. Presumably 15% would be the overall system performance, including legacy 32-bit applications?
You see when you have a 64bit memory addressing and can optimize for this in the memory manager you no longer have FS and pagefile lookkup tables for extended amounts of RAM.
What is a FS (filesystem?) lookup table?
You also can do like Vista x64 does and shove two 32bit memory writes into on 64bit address space, so when it can, you get double the read/write performance out of the memory chip because you are pulling two 32bit chunks in one read cycle.
By "64 bit address space" I presume you mean 64 bit register (you fit 2^32 32bit address spaces in a 64bit address space). But even in 32bit mode Intel CPUs can access 128bit registers via SSE. Anyway, this presumably has more to do with your compiler than your OS, so I don't know what Vista has to do with this.
Everything else being equal, 64bit software would run slower than 32 bit, because you need twice as many bits to represent a pointer. Essentially, unless you need an address space larger than 4GB, you are wasting 32bits on every pointer. This would waste memory, cache and memory bandwidth etc. The standard answer as to why 64bit software runs faster on Intel/AMD CPUs is that on these CPUs everything else is *not* equal.
The biggest bonus to running in 64bit mode on Intel/AMD chips is that since 64bit is essentially a whole new arch, we can throw out all the backward compatibility. In 64bit mode we actually have a decent number of registers. Also since 64bit code won't run on old processors anyway, there is no point in compiling code to be backward compatible with the old i586.
Understand yet?
Not really. Not any better than I understand this paper anyway :P. Could you give links explaining your claims above?
It is a kernel. Just FYI. This would have to be the first time any Slashdot* reader has needed Linux (or BSD) to be defined
* When I said I used Linux, I once got the response "So, do you really have sex on it?". This was not on Slashdot though
Well, at the moment we don't really have the command line as a failsafe. When the X server crashes it seems to lock up the keyboard so Cntl-Alt-F1 doesn't switch to the VT (though I can usually ssh in, and restart X, but then I could also ssh -Y and restart X with a remote GUI, so the "commandline" doesn't really help here).
The problem is the currently we have three different things that can directly mess with the video hardware: The framebuffer, DRI and the X server, and so any of these can cause trouble. This can lead to worse than triple the number of bugs because interactions between these can cause trouble.
Its similar to how having a database server tends to be more reliable than having clients directly accessing the database files. Yes, the database server adds a single point of failure, but that is better than having 20+ nodes each of which can horribly corrupt the database files. While in principle GEM could fail, so could the hundred other modules in my kernel. And a bug in GEM is unlikely to be as serious as a bug in ext3/4.
(eom)
I mainly used it for Maple V. When I had an nVidia card I also used it to play Team Fortress II with my windows friends.
One thing to consider: the applications you describe run fine in any virtualization software, where as 3D games do not. Even if your virtualization software supports 3D it might have a very heavy overhead. Apparently Hardware Lighting is 87% slower in Parallels 3. Thus it is reasonable that getting popular 3D intensive applications to run in Wine is a priority.
Also note that CrossOver Office is based on Wine, and that some software producers officially support Wine (e.g. Google supports running Picasa under wine). So, despite its problems I still like Wine... I also like Wine Is Not an Emulator ;)
Eh, I don't see anything impressive about having a popularity contest either. More interesting is the list of applications that are actually supported, e.g. the productivity applications that work without any flaws.
I don't know what you mean by "Relax on APIs". However WineLibs makes porting applications to Linux much easier. Wine is Not an Emulator, it is a reimplementation of the Win32 libraries. This means that it need not be slower, and even though Wine is not fully optimized it is already faster than Windows XP in some areas. If your app doesn't just instantly work in Wine then you have found a bug in Wine*, you just have to fix or workaround that bug. Otherwise you'd have to change every part of your program.
* or you have found a buffer overrun that just happens not to be detected by Windows. Congratulations. Also tweaking the GUI a bit would help so it would fit in better, but not strictly speaking essential
Also, I imagine that Asus paid far less for the 4GB SSD on the Eeepc 701 than they would have paid for any harddisk. The claim that hdds are cheaper is presumably per GB rather than per device which is perfectly capable of standard tasks such as word processing.
Although it is less than 20% of the total footprint of life-cycle of the car. I understand that refining the metal to make the batteries is fairly polluting. However it is very easy to recycle the metal, and since the metal is reasonably valuable there is a significant financial incentive to do so. I am not sure how much the metal is worth but Toyota pays $200 for hybrid batteries (Toyota may be subsiding this so the actual metal is worth less).
Our engineers are stealing all your ideas and putting them into pagerank. Mwahahahaha!
Zip! Nada! In fact when they send packets over my network connection they pay a *negative* amount! If you want to find the real bandwidth hogs, it is the Telcos.
All those people who browse http://localhost/ at ridiculous speeds without paying a cent are pretty greedy too.
... Back in the real world there is central node called "The Internet" that has to route all traffic. If you want to connect to someones network they may ask for money, if they want to connect to your network, you can ask them for money. How much money is up to you and them.
Turns out Wikipedia got to censor edits from the UK ISPs as well. ;)
The smaller the stack size, the easier it is to allocate memory for the stack, but also the harder it is to write drivers etc. that don't overrun the stack.
Most allocations in a paging system are done by page. A 8k stack on x86 means that you need to find two adjacent free pages, finding two adjacent pages can be difficult. A 4K stack means that you only need to find one page, i.e. so long as there are pages free you can easily allocate a 4K stack. Thus there is little benefit to having a stack smaller than 4K, having a 1K stack would save a small amount of memory, but wouldn't make it any faster to allocate a new stack.
The lower limit on Fragmentation? Not really. If you have a hundred more mallocs than frees, you'll have to track one hundred mallocs and perhaps another hundred chunks of free space. A smarter algorithm can use clever heuristics to avoid some fragmentation at the cost of performance, but if anything this would usually result in less chunks of free space. At the end of the day no matter how smart the algorithm or how many chunks it manages, if you allocate memory in 32bytes chunks and then free all but one 32 byte chunk from each 4K page, you'll end up with 99% fragmentation.
I don't know about BSD, but Linux now uses the 2Q allocator. This means that the cache will be released shortly, unless it is accessed a second time. This should prevent updatedb etc. from forcing out all other pages out of RAM by trying to cache the entire contents of the harddisk.
If you have a single 32 byte fragment in a 4KB page, you cannot release the page back to the OS. If you can reduce memory fragmentation by 1% you reduce the amount of memory you need to request from the OS by 1%. There is still work being done on allocators that minimize fragmentation. It is not clear how you can defragment memory after it has been allocated though. It would be very hard to safely update the pointers in a C program to point to the new memory locations after defragmentation. Possibly these memory defragmenters move around pages of virtual memory so that the kernel can allocate 8KB and larger chunks of physical memory (Kernels typically bypass VM and prefer pages that are physically adjacent). I understand that the motivation for the 4K stacks in the Linux Kernel was the difficulty in finding two adjacent free physical pages. This would be even more of an issue on Windows which apparently use 12K stacks.
Assuming 1400 byte max packet data, 8 bytes of file position (i.e. files may be bigger than 4GiB), 4 bytes to give the index of a file, that's 1388 byte packets... 3094357 packets at least for 4GB, an extra 32MB.
Note that UDP packets are 12 bytes smaller than TCP, so we are already breaking even. Since we control the protocol, we could e.g. download files in 4GB chunks so that we could use an 4 bytes of file position. In principle we could also have the source IP and port number uniquely identify the file, and thus eliminate the the file index from the packet. Then we are saving 8 bytes per packet by using UDP.
Even the latest EeePC models still come with XP (or Linux). Windows Business licenses allow installation of XP, and you still get the occasional non-netbook machine with XP pre-installed. However from the summary itself, if you really want to stay with XP, one option is just to buy a *used* XP machine. There are people still running Mac Classics out there.
Here is a link that discusses this further. They mention that a human can see an object that is displayed for one 500th of a second, if it is bright enough. In RL your eyes do the motion blur for you. This is also similar to how anti-aliasing works, which in its basic form is rending the frames at a higher resolution than the monitor can display and then downsizing the picture so we can averaging the pixels.
This has already been pointed out half an hour ago. FYI, the second link is 2008.
Dell has been caught red-faced: 2005
... apologized ... : 2008
I think your example is rather extreme. First of all, if the aeroplane didn't crash the claim would be obviously false. If the aeroplane did crash the there would be huge inquiry, the engineer/aggressor who decided to misuse the OS code in a place would also bear liability and would be in a world of pain. If so much as a hint got out that they intentionally crashed the plane then they would be charged with a hundred counts of homicide... and thats if they are lucky enough not be a tried under anti-terrorist law.
The realistic outcome would be that someone yanks the code out of somewhere, doesn't bother to check it, and decides to sue someone. IANAL, (and I am certainly not a lawyer in every jurisdiction of the world) but the common wisdom is that even when suing a company you've paid for software the courts have held that it is the buyers responsibility to check suitability, not the producer of commodity software.
Well yes but, it is never the bug you are expecting that bites you in the final release (was it a final release? it was RC29). It is always the bug that is so mindbogglingly stupid that you never think to check for it.
I don't *think* it much of a "security" flaw, as you say; but you don't want random command being run as root with random arguments. Who knows what would happen? Infact administrators often spend most of their time logged in as a non-root users so they don't accidentally do stupid things. Having every thing you type run as a root command is badly broken.
It'd be really annoying just having the system reboot whenever I tell someone to
retry
reboot
CARRIER LOST.
Kind of like the Year of the Desktop for Linux.
The obvious way is to pick some random unrelated software project and threaten to use windows unless they rewrite it to be a medical app. This is the number one n00b mistake. You will be quickly identified as a troll and hounded off Slashdot.
Instead continually praise the unrelated app as being the best biomedical confubulator ever written. Then you'll have thousands of users attempting to use it as a biomedical confubulator getting angry and threatening to switch to windows for you.
The best thing about this technique is that the Slashdot hive mind will never catch on, and in fact everybody who contradicts you by saying that your victim project can't do medical confubulations, *they* will be labeled as a troll and hounded off Slashdot. The technique is infallible I tell you ;)