Add to that the fact that you only need to do this once. After that, you can download small 2-5MB patches to incrementally apply to the tree you already downloaded to go from any version to any other version, as they are released.
You can also use git and get compressed binary packs of around 1MB to switch your tree from any release to any other release in seconds.
Umm. You can't sigkill init on Linux (at least on moderately recent kernels). I am pretty sure that is also the case on BSD systems.
Yep... In arch/i386/kernel/signal.c [2.6.17-rc1-mm2]
563/* 564 * Note that 'init' is a special process: it doesn't get signals it doesn't 565 * want to handle. Thus you cannot kill init even with a SIGKILL even by 566 * mistake. 567 */ 568 static void fastcall do_signal(struct pt_regs *regs)
Havok is the primarily used API in the gaming industry. It is the one being targeted by this implementation.
That said, it would presumably be possible to implement other APIs (if there is sufficient demand), given that the GPU hardware is now general enough to handle that level of computation.
Many many people already have a capable GPU and would only need a driver/software update.
The physX card is considerably more cumbersome to use for the average gamer, and is consequently less likely to be supported by game developers. Not to mention the fact that the cards are likely to be quite expensive.
I used brook to compute some SVM calculations, and my 7800GT was about 40x faster than my Athlon64 3000+ (even after I hand-optimized some loops using SSE instructions). So its perfectly understandable for physics to be 10x faster on the GPU.
Having a dedicated card for this is not worth the effort for most people. Not to mention the fact that such niche hardware will be very expensive, and limited to the realm of hardcore gamers, whereas NVidia's GPUs are (almost) everywhere.
given than GPU->CPU readbacks are a notorious perfomance killer.
That has not been true for a long long time. Since PCIe became a standard, bidirectional communication between CPUs and GPUs has been as easy as unidirectional communication.
Being in debt is the best way to learn how to manage money properly.
When the politicians involved have to deal with smaller bugdets and large debts they will be better at managing money in the future and likely spend less on frivolous laws. That is, unless the population of the state agress with the law in question, in which case this kind of thing will continue indefinitely.
Some functions cant be passed through, they need to be emulated, even on the same architecture, redirecting memory, storage and I/O requests, interrupt handlers and such. All these things suck performance, and in the case of games, where LOTS of memory and low-level calls to the graphics hardware are being made, performance sucks BADLY.
Any gamer will notice a loss of 15 FPS or more in their favourite game. Developers will notice it too, when their profilers output does not match their codes timing.
You can't play with the time, even if you are in a VM. People will notice this - even if the software wont.
due to use of Intel-only prefetch instructions or whatever
The AMD instruction set is a strict superset of the Intel instruction set. There are no Intel-only instructions anymore. There are however many AMD-only instructions (3dnow, 3dnow+, etc.), so if the situation were reversed, there might have been a legitimate claim, but since the AMD CPUs were locked out, it is clearly a bribe^Wmarketing descision.
Just tweak your proxy or browser's configuration to append "-inurl:about.com" to google queries.
Google will not arbitrarily filter stuff out like about.com since quite a few people actually use it. At best google will allow you to customize google.com/ig to filter sites, but all those queries will be logged with your username, which is something I would rather avoid.
they should give the money to the first person that can get nVidia/ATI drivers working inside a VM
What good would that do? There isn't an nVidia/ATI card in the VM to work on! The VM has its own virtual graphics card. No other card's drivers will do.
Besides, there is just too much overhead to do this kind of thing in the VM at the driver level. They could theoretically create their own DirectX implementation that worked with the hosts drivers, but this seems like a LOT of work for a small gain.
Gaming performance sucks inside VMWare. The only way I will buy a mac notebook is if I can still play games on it. If windows works on it, then I am definitely going to buy one.
Moore's law says nothing about speed or frequency of the CPUs... merely that the transistor count will double every 18 months. And, so far it has. My Athlon-64 X2 4800+ has double the transistor of my best CPU 18 months ago (give or take a bit for cache).
BSD jails share the kernel, Xen systems have their own kernels (patched versions of the actual Linux/BSD/etc kernels) and communicate with the host kernel through the vizor. Xen can run multiple different kernels and also support all the features such as advanced routing and access to host hardware.
Jails are lighter/faster but less secure (a kernel exploit in a jail will root the whole system).
If you prefer working with VTune, just use VTune. At a high level, it doesn't matter whether you are working on an AMD or Intel CPU since the.NET JIT code will be almost identical.
The intel tools are absolutely fantastic and integrate perfectly with VS and most other.NET tools. Its not worth your time and effort to use inferior products just for the sake of using AMD hardware. Just profile your code on an intel box and depoly on any box (since.NET doesn't care).
I have't worked much with.NET, but for C++ nothing beats intel's C++ compiler and profiling tools. Even though I strongly prefer AMD hardware (I don't use laptops much), I keep a few intel boxes around for developing high performance C++.
Use multiple drives ripping at once. There are at least two drives in any decent machine, and probably two or three machines at least in any self-respecting geek's place.
Slashdot Mirror
Add to that the fact that you only need to do this once. After that, you can download small 2-5MB patches to incrementally apply to the tree you already downloaded to go from any version to any other version, as they are released.
You can also use git and get compressed binary packs of around 1MB to switch your tree from any release to any other release in seconds.
Yep
In arch/i386/kernel/signal.c [2.6.17-rc1-mm2]
They are not x86 compatible. They are RISC like chips with an instruction set optimized for for running VM based applications like Java and .NET.
That said, its still very impressive to get that many cores working together, though not as impressive as x86.
Bad drivers.
That is also the reason DirectX is so much slower than what the bus is capable of.
PCI Express became an approved standard on the 17th of April, 2002.
:)
Welcome to the future
Havok is the primarily used API in the gaming industry. It is the one being targeted by this implementation.
That said, it would presumably be possible to implement other APIs (if there is sufficient demand), given that the GPU hardware is now general enough to handle that level of computation.
You can; look at Brook GPU and libSh.
Many many people already have a capable GPU and would only need a driver/software update.
The physX card is considerably more cumbersome to use for the average gamer, and is consequently less likely to be supported by game developers. Not to mention the fact that the cards are likely to be quite expensive.
10 times faster is not all that unreasonable.
I used brook to compute some SVM calculations, and my 7800GT was about 40x faster than my Athlon64 3000+ (even after I hand-optimized some loops using SSE instructions). So its perfectly understandable for physics to be 10x faster on the GPU.
Having a dedicated card for this is not worth the effort for most people. Not to mention the fact that such niche hardware will be very expensive, and limited to the realm of hardcore gamers, whereas NVidia's GPUs are (almost) everywhere.
given than GPU->CPU readbacks are a notorious perfomance killer.
That has not been true for a long long time. Since PCIe became a standard, bidirectional communication between CPUs and GPUs has been as easy as unidirectional communication.
Being in debt is the best way to learn how to manage money properly.
When the politicians involved have to deal with smaller bugdets and large debts they will be better at managing money in the future and likely spend less on frivolous laws. That is, unless the population of the state agress with the law in question, in which case this kind of thing will continue indefinitely.
Some functions cant be passed through, they need to be emulated, even on the same architecture, redirecting memory, storage and I/O requests, interrupt handlers and such. All these things suck performance, and in the case of games, where LOTS of memory and low-level calls to the graphics hardware are being made, performance sucks BADLY.
Any gamer will notice a loss of 15 FPS or more in their favourite game. Developers will notice it too, when their profilers output does not match their codes timing.
You can't play with the time, even if you are in a VM. People will notice this - even if the software wont.
For someone like me, who games on his PC a lot as well as working, it would be immediately obvious that there is something wrong.
Gaming performance would take a serious hit, as would anything that would normally require privileged hardware access.
No virtual machine can work as fast as the host system or with as much RAM.
Actually, current AMD CPUs (including the X2's I am talking about) DO have the cmpxchg16b instruction.
u rces/0,,30_182_739_7044,00.html
See: http://www.amd.com/us-en/Processors/TechnicalReso
The AMD instruction set is a strict superset of the Intel instruction set. There are no Intel-only instructions anymore. There are however many AMD-only instructions (3dnow, 3dnow+, etc.), so if the situation were reversed, there might have been a legitimate claim, but since the AMD CPUs were locked out, it is clearly a bribe^Wmarketing descision.
Just tweak your proxy or browser's configuration to append "-inurl:about.com" to google queries.
Google will not arbitrarily filter stuff out like about.com since quite a few people actually use it. At best google will allow you to customize google.com/ig to filter sites, but all those queries will be logged with your username, which is something I would rather avoid.
they should give the money to the first person that can get nVidia/ATI drivers working inside a VM
What good would that do? There isn't an nVidia/ATI card in the VM to work on! The VM has its own virtual graphics card. No other card's drivers will do.
Besides, there is just too much overhead to do this kind of thing in the VM at the driver level. They could theoretically create their own DirectX implementation that worked with the hosts drivers, but this seems like a LOT of work for a small gain.
Gaming performance sucks inside VMWare. The only way I will buy a mac notebook is if I can still play games on it. If windows works on it, then I am definitely going to buy one.
I think we have finally solved the infamous 2. ??? puzzle.
Moore's law says nothing about speed or frequency of the CPUs... merely that the transistor count will double every 18 months. And, so far it has. My Athlon-64 X2 4800+ has double the transistor of my best CPU 18 months ago (give or take a bit for cache).
BSD jails share the kernel, Xen systems have their own kernels (patched versions of the actual Linux/BSD/etc kernels) and communicate with the host kernel through the vizor. Xen can run multiple different kernels and also support all the features such as advanced routing and access to host hardware.
Jails are lighter/faster but less secure (a kernel exploit in a jail will root the whole system).
If you prefer working with VTune, just use VTune. At a high level, it doesn't matter whether you are working on an AMD or Intel CPU since the .NET JIT code will be almost identical.
.NET tools. Its not worth your time and effort to use inferior products just for the sake of using AMD hardware. Just profile your code on an intel box and depoly on any box (since .NET doesn't care).
.NET, but for C++ nothing beats intel's C++ compiler and profiling tools. Even though I strongly prefer AMD hardware (I don't use laptops much), I keep a few intel boxes around for developing high performance C++.
The intel tools are absolutely fantastic and integrate perfectly with VS and most other
I have't worked much with
How would you know? Most spyware is very hard to detect (no extra processes, no extra visible system activity, very small memory footprint).
Use multiple drives ripping at once. There are at least two drives in any decent machine, and probably two or three machines at least in any self-respecting geek's place.
/heh, please type the word in this image: coaster