Well, most CPUs will schedule the instructions to the floating point units on their own. That means it's not a very hard problem to write a compiler that makes decent use of it. The normal memory management system is also used, with virtual memory, automatic transfer of data to and from cache lines, and so on. The cell vector units seem to operate on their own, with their own cache which has to be handled manually.
It's non-trivial enough to auto-SIMD code. I would say that this is somewhere between using SIMD properly and offload more stuff to the GPU, if you try to estimate the inherent difficulty. For example, is Quartz employing vertex shaders for text rendering? It could be done, if done properly it could even be faster than current text rendering, but I doubt that it's been done (yet).
But, read his points! The reason he lists are mostly not security, in fact, but reliability, where he deems the relatively open "PC compatible" space as flawed. Sheesh, I can't even recommend you to RTFA, because of its lack of substance.
I'm not enough into the finer points of 3D creation to say for sure what commercial tool Blender matches best, but if these were the best examples of free software innovation, then I'm scared. It's great execution of a rather known concept, but then Windows NT was "innovation" just by implementing a somewhat stable, somewhat compatible, somewhat scalable GUI-supporting OS on x86. Hey, all of it had been done before, but not in that specific combination, so it's innovation! Right...?
I think there are many projects with free or open source that are innovative. But I do also think that many of those spring from someone's PhD thesis or in a similar context. That is, they view it as work, but as they are not out to make a buck out of the code itself, it's published.
It's hard to do something really innovative. It's also true that a technological revolution doesn't have to start with something innovative being created. It starts when this idea, that dozens or thousands of people may have tossed around with earlier, is turned into something that's available and usable by millions.
It's said that x64, both for XP and 2003 Server, were based on the Windows 2003 Server SP1 code tree. Probably, they always keep build target for multiple editions in the code tree, but that doesn't mean that they care a damn shit about build usability for the Home edition of the 2003 tree, while 2003 was developed. Building a Home release would still be quite more simple than backporting every relevant change that made it into the 2003 codebase.
On the other hand, it is downright easy to write code that assumes endianness. This would probably be The Most Important problem in general porting of Windows code (and to some degree x86 in general) to other architectures. Back in the NT-porting days, I still think all CPUs were in a "LE" mode. I frankly don't know anything about whether this is the case for the Xbox 360.
Hey, what about the other way round? There is no good, free Java implementation of any kind for recent WinCE. (Kind of obvious, since there is no good, free Java at all. Maybe one should start contributing.)
I imagine it could possibly be simpler to get J# code from MS running, combined with the NetCF and a byte-code converter from Java. Kind of like running Win95 in Bochs on your PDA... (i.e., useless)
How would a "DRAM disk" solution possibly get cheaper than normal RAM? Of course, you may "afford" a lower frequency, but I don't think you really gain that much below a certain level, as the yield can't get any better than 100 %. Of course, it's impossible to connect 16 GB of DRAM to most mainstream memory controllers today, and a specific controller + memory pack could be cheaper than a server board allowing that, but I don't think that an "all-DRAM" solution is very feasible; especially not swap on it?
What I would like, though, would be to mount the free part of the video RAM as a hard-drive backed file system. You could put a swap on that one and actually get better performance in the end, althouth only for a few (hundred) MBs.
OTOH, we haven't yet been able to measure for example Avogadro's number (about 6x10^-23, the number of atoms in one mol). As long as we haven't been able to measure something with this precision (I don't think any other quasi-fundamental constant is known to that accuracy, either), it will sure take some time before we can control something with such precision.
It's not that hard to detect serotonin and other neurotransmitters with reasonable resolution. You can do it by magnetoresonance spectroscopy. (MRS, the sibling of MRI, but you look for very specific chemical shift signatures instead of just detecting water or some other abundant substance.)
The resolution is kind of crap today (far from the neuron level), but that's a matter of both magnetic field strength and the signal post-processing.
The Swedish public broadcasting has not acquired a license to air the material or retransmit it freely (as in speech) only "for free", as in beer. (And only if you ignore the license for a moment.) If you rent a video for the weekend, you're likewise not allowed/supposed to copy it and watch it some other time.
Now, this analogy is distorted by the fact that it's considered fair use to record a TV show for later, personal, viewing, but the principle remains the same -- you (directly or through the public broadcasting "proxy" of yours) did never pay up for a general license. Which revenue model the broadcaster decides to pursue is of no relevance here.
Nope, Intel has, for example significant facilities in Ireland and Israel. (Hey, maybe they just look for countries matching I*el*...)
In addition to this, there are also assembly factories, using the finished cores and packing them up in for example Costa Rica and Malaysia.
This was more or less from the top of my head, so there may be some errors and significant omissions here. I don't remember offhand, for example, if there are any significant East-Asian Intel semi fabs. I also found this Intel marketing site which might provide some more information.
Nah, it will have to reach a temperature close to the melting point to actually absorb heat in any other way than an ice cube may absorb heat when its -5 centigrades. You can't get a higher temperature in the coolant than in the "colee", so to cool by the phase transition itself, you'll need the colee to reach the melting point of the metal. That will also be needed if one is going to get a pump going by magnetic forces, which seems to be the idea here. If it stays solid, it will only be a fancy, encased, heatsink.
On my SonyEricsson Z1010 with camera, video calls, media player, J2ME goodness, I still just press "down" to navigate my phone book. If I press a number key after doing so, I scroll to that letter. With the left menu button, I have direct access to my call list, both outwards and inwards. I can easily place another call to the same number.
Point being? Lots of features don't have to make the obvious and common ones hard to access. Thanks to a larger, color, display, it's also easier to find what I want in the menus, when I need to access those, as I can view all available options at the top level, compared to previous Nokia phones, where I could only see one at a time and scroll between them.
I can call with my phone, from the phone book, easily. No configuration or menu madness. I can create simply key shortcuts to those of the more complex features I actually use. And then, I have a userfriendly menu for other stuff, when I need that. If cramming in more features has made your phone hard to use, that's because of bad implementation, not because of the features.
But, please, this isn't rocket science. It would be fun to extract it efficiently, both as fuel in Luna-launched rockets* and for human breathing. BUT, we have a really good idea of all kinds of way to process geologic material. They are asking for a recipe on how to make a great cake. Baking cakes are nothing new, but the list of ingredients here is a little peculiar, so it may take some thinking to come up with a good result.
Put another way, this is engineering, not science, if you try to idealize a distinction between the two.
And the difference is quite important. It's (relatively) easy to get a synchronization to the orbit of the celestial body that's controlling you with its gravitational pull. It's harder to pinpoint the position of another object, also spinning around the same celestial body.
Compare it to these three settings:
Just capturing a picture of a baseball, lying on the ground.
Capturing a picture of the same ball, while in flight.
Capturing a picture of the same ball, while you yourself is going in a comparably sized object in a different direction.
It's important that it is a satellite. That makes it more impressive than localizing ground structures with known positions... unless those structures are very small, like the polar lander. Then, it's also kind of impressive, but for mostly different reasons.
There was no IE at all when vanilla Windows 95 was released. It was released quickly afterwards in the infamous Plus! package. It started to be bundled, but not that "integrated" in Windows 95 OSR2. IE 4 was really integrated in OSR 2.5 and, naturally, Windows 98.
A few simple things that's clearly causing a little bit of the different memory requirement is the fact that Windows XP is all 16-bit characters inside. Every string is 16-bit, in the kernel, and many in user mode, too. Similarly, many 16-bit code and data pages in Win95 have 32-bit equivalents in XP. Both these will contribute to a 100 % increase in memory usage. Many fonts are also 16-bit now, with many more glyphs actually available than back in 95. Unused glyphs won't hurt you that much, but it all adds up.
Another thing that directly influences the memory usage is the fact that a simple 95 user would run something like 640 * 480, 256 colors. A simple XP user will *at least*, no matter if you run Fisher Price or not, use 800 * 600 * 16 bit. This is a factor 3.125. Of course, the frame buffer itself will be on the graphics adapter, but in practice you can be quite sure that the system will keep offscreen bitmaps and buffers.
Finally, did your 95 machine use disk DMA? I dare to say not. To get decent throughput these days, I wouldn't be surprised if more than all the 4 MB of the original Windows 95 are used directly by DMA buffers, nonpaged memory mapped to hardware.
Finally, I've forced and been forced to use both Windows 95 with 4 MB and Windows XP with 64. With very little trimming of XP, it was usable for simple tasks. In the original '95 release, you couldn't trim anything away if you wanted to use it. In fact, you had to install a web browser just to use it as a thin web client.
There is considerable bloat. I would, however, say that I prefer the stability of XP over the argued "leanness" of '95.
In a way, it's easier with a blank hardware check. You have a easy target - make it faster and keep as much useful stuff we already have done (if any....) as possible. They also, naturally, want to maintain the compatibility to the current API, broken or not.
Longhorn is different. It's supposed to make all that hardware actually seem useful, doing something novel about it. It's easy to make a slow crapload just imitating XP. Hopefully, they try to do just a little (maybe very little) more than that. That's treading into unknown land, and an unpredictable process. Optimizing isn't. You may not know how well you optimize, but the overall target is quite set and it's easy to measure how close you are to attaining it.
But you don't override priviledges per se. You just indirectly retrieve seemingly innocent data about how long it takes to run your memory access loop repeatedly. The simplest and most obvious, total, solution would be to cut the maximum cache used by any thread in half, while HT is enabled. This would seriously harm HT, though. While simple in theory, it's also not that simple to add back into an existing design, especially if you want to keep the ability to run "full cache" for a single thread.
I'm not very sure if I prefer the C notion that passing an array is actually always passing down a reference to it. Or that objects, but not primitives, are always passed by reference in Java. Try to teach a class what the stack is and that parameters are just funky names you give to copies of your data, when so much of it is still treated like they weren't copies at all.
In C (and even more so in Java) you shoot yourself in the foot in the foot by accident, you get the wrong results from what a naive interpretation of the syntax from a general computer science standpoint could indicate. In Pascal, you get what you asked for. It's stupid, but it is what you asked for.
Because Standard Pascal is a heck to handle. Just try doing file I/O. Or strings. Turbo Pascal (=> Object Pascal => Delphi) or any "modern" edition is/was quite nice, but on the other hand much more similar to a somewhat cleaner and radically more verbose C++. I switched without much pain from Pascal to C in 1997 and I think afterwards that my style of Pascal was really just bending the language to try to fit in what is easy allowed by the freer C syntax.
Slashdot Mirror
It's non-trivial enough to auto-SIMD code. I would say that this is somewhere between using SIMD properly and offload more stuff to the GPU, if you try to estimate the inherent difficulty. For example, is Quartz employing vertex shaders for text rendering? It could be done, if done properly it could even be faster than current text rendering, but I doubt that it's been done (yet).
But, read his points! The reason he lists are mostly not security, in fact, but reliability, where he deems the relatively open "PC compatible" space as flawed. Sheesh, I can't even recommend you to RTFA, because of its lack of substance.
Agreed. Also note that Star Trek, in its better moments (certain recent features excluded), belongs in the latter group.
Gimp? "Hey, we want a free PhotoShop."
PHP? "Hey, we want a free and C-like ASP."
MySQL? "Hey, we want a free (kind'a) RDBMS."
I'm not enough into the finer points of 3D creation to say for sure what commercial tool Blender matches best, but if these were the best examples of free software innovation, then I'm scared. It's great execution of a rather known concept, but then Windows NT was "innovation" just by implementing a somewhat stable, somewhat compatible, somewhat scalable GUI-supporting OS on x86. Hey, all of it had been done before, but not in that specific combination, so it's innovation! Right...?
I think there are many projects with free or open source that are innovative. But I do also think that many of those spring from someone's PhD thesis or in a similar context. That is, they view it as work, but as they are not out to make a buck out of the code itself, it's published.
It's hard to do something really innovative. It's also true that a technological revolution doesn't have to start with something innovative being created. It starts when this idea, that dozens or thousands of people may have tossed around with earlier, is turned into something that's available and usable by millions.
It's said that x64, both for XP and 2003 Server, were based on the Windows 2003 Server SP1 code tree. Probably, they always keep build target for multiple editions in the code tree, but that doesn't mean that they care a damn shit about build usability for the Home edition of the 2003 tree, while 2003 was developed. Building a Home release would still be quite more simple than backporting every relevant change that made it into the 2003 codebase.
On the other hand, it is downright easy to write code that assumes endianness. This would probably be The Most Important problem in general porting of Windows code (and to some degree x86 in general) to other architectures. Back in the NT-porting days, I still think all CPUs were in a "LE" mode. I frankly don't know anything about whether this is the case for the Xbox 360.
I imagine it could possibly be simpler to get J# code from MS running, combined with the NetCF and a byte-code converter from Java. Kind of like running Win95 in Bochs on your PDA... (i.e., useless)
What I would like, though, would be to mount the free part of the video RAM as a hard-drive backed file system. You could put a swap on that one and actually get better performance in the end, althouth only for a few (hundred) MBs.
OTOH, we haven't yet been able to measure for example Avogadro's number (about 6x10^-23, the number of atoms in one mol). As long as we haven't been able to measure something with this precision (I don't think any other quasi-fundamental constant is known to that accuracy, either), it will sure take some time before we can control something with such precision.
Better do it quick, before he downloads himself without realizing that he's the only one that knows the encryption key.
The resolution is kind of crap today (far from the neuron level), but that's a matter of both magnetic field strength and the signal post-processing.
Now, this analogy is distorted by the fact that it's considered fair use to record a TV show for later, personal, viewing, but the principle remains the same -- you (directly or through the public broadcasting "proxy" of yours) did never pay up for a general license. Which revenue model the broadcaster decides to pursue is of no relevance here.
In addition to this, there are also assembly factories, using the finished cores and packing them up in for example Costa Rica and Malaysia.
This was more or less from the top of my head, so there may be some errors and significant omissions here. I don't remember offhand, for example, if there are any significant East-Asian Intel semi fabs. I also found this Intel marketing site which might provide some more information.
(BTW, the brand name Lada means something like barn in Swedish.)
Nah, it will have to reach a temperature close to the melting point to actually absorb heat in any other way than an ice cube may absorb heat when its -5 centigrades. You can't get a higher temperature in the coolant than in the "colee", so to cool by the phase transition itself, you'll need the colee to reach the melting point of the metal. That will also be needed if one is going to get a pump going by magnetic forces, which seems to be the idea here. If it stays solid, it will only be a fancy, encased, heatsink.
That sure sounds like a nice way to say "two slots" to me.
Point being? Lots of features don't have to make the obvious and common ones hard to access. Thanks to a larger, color, display, it's also easier to find what I want in the menus, when I need to access those, as I can view all available options at the top level, compared to previous Nokia phones, where I could only see one at a time and scroll between them.
I can call with my phone, from the phone book, easily. No configuration or menu madness. I can create simply key shortcuts to those of the more complex features I actually use. And then, I have a userfriendly menu for other stuff, when I need that. If cramming in more features has made your phone hard to use, that's because of bad implementation, not because of the features.
Put another way, this is engineering, not science, if you try to idealize a distinction between the two.
Compare it to these three settings:
It's important that it is a satellite. That makes it more impressive than localizing ground structures with known positions... unless those structures are very small, like the polar lander. Then, it's also kind of impressive, but for mostly different reasons.
A few simple things that's clearly causing a little bit of the different memory requirement is the fact that Windows XP is all 16-bit characters inside. Every string is 16-bit, in the kernel, and many in user mode, too. Similarly, many 16-bit code and data pages in Win95 have 32-bit equivalents in XP. Both these will contribute to a 100 % increase in memory usage. Many fonts are also 16-bit now, with many more glyphs actually available than back in 95. Unused glyphs won't hurt you that much, but it all adds up.
Another thing that directly influences the memory usage is the fact that a simple 95 user would run something like 640 * 480, 256 colors. A simple XP user will *at least*, no matter if you run Fisher Price or not, use 800 * 600 * 16 bit. This is a factor 3.125. Of course, the frame buffer itself will be on the graphics adapter, but in practice you can be quite sure that the system will keep offscreen bitmaps and buffers.
Finally, did your 95 machine use disk DMA? I dare to say not. To get decent throughput these days, I wouldn't be surprised if more than all the 4 MB of the original Windows 95 are used directly by DMA buffers, nonpaged memory mapped to hardware.
Finally, I've forced and been forced to use both Windows 95 with 4 MB and Windows XP with 64. With very little trimming of XP, it was usable for simple tasks. In the original '95 release, you couldn't trim anything away if you wanted to use it. In fact, you had to install a web browser just to use it as a thin web client.
There is considerable bloat. I would, however, say that I prefer the stability of XP over the argued "leanness" of '95.
Longhorn is different. It's supposed to make all that hardware actually seem useful, doing something novel about it. It's easy to make a slow crapload just imitating XP. Hopefully, they try to do just a little (maybe very little) more than that. That's treading into unknown land, and an unpredictable process. Optimizing isn't. You may not know how well you optimize, but the overall target is quite set and it's easy to measure how close you are to attaining it.
But you don't override priviledges per se. You just indirectly retrieve seemingly innocent data about how long it takes to run your memory access loop repeatedly. The simplest and most obvious, total, solution would be to cut the maximum cache used by any thread in half, while HT is enabled. This would seriously harm HT, though. While simple in theory, it's also not that simple to add back into an existing design, especially if you want to keep the ability to run "full cache" for a single thread.
In C (and even more so in Java) you shoot yourself in the foot in the foot by accident, you get the wrong results from what a naive interpretation of the syntax from a general computer science standpoint could indicate. In Pascal, you get what you asked for. It's stupid, but it is what you asked for.
Not that the C syntax is only a good thing....