So far as I can see, I'm supposed to dump my compiler for something that lets me use half a dozen instructions I can get with inline assembly or Intel's _free_ compiler, where Windows is concerned.
Well clearly I can't agree with your viewpoint on what a proper vectorizing compiler is capable of doing. Now if you're prepared to go do all the inline assembly for the various SIMD implementations on x86 CPUs then indeed, you have no use for VectorC. However that's pretty rare for game developers working to deadlines in my experience.
I totally agree, writing SIMD assembly for each platform you want your code to run on is waaaay too much effort when you have deadlines to deal with.
I assume that if Snowfox thinks that there are only a dozen instructions for SIMD operations in games programming, then he is sorely mistaken. The PS2 has _loads_ of vector operations, and I find that it's much more productive to have tools which will do that, along with scheduling the resulting vector operations efficiently, for me.
Also, some media processors have literally _hundreds_ of vector instructions, and even remembering which one of those instructions is suitable for a single operation is hard enough to remember! Leave it to the compiler, I say:)
I would love to see a game that could take advantage of a dual 1.4 GHz athlon with a GeForce3. So, smp?
This isn't a compiler issue, as separation between multiple processors from a single program will need explicit multi-threading or multiple processes -- automatically finding enough parallelism from a single program to acheive this is very much a research topic at present, except for a very few well-tested and simple cases.
However it would be great if this compiler (or maybe a version of this compiler) had a license friendly enough that if someone chose to purchase and develop with it they would be able to distribute the source code under a license they choose.
The current version already allows this, as far as I know from using it, as to place restrictions on the use of the source code you have written yourself and compiled with VectorC would really be shooting themselves in the foot...
Besides, the idea is that the compiler and generated object files are 100% compatible with what you already have (source code and object files), so there is no need to `program the kernel with it' as the code will be no different to standard C code.
I dont know if it will ever be able to compile the linux kernel, but I used VectorC in one of my projects and it did improve the performance significantly without compiling the whole thing.
If the gcc-compatibility is up to par, then it should be possible at some time in the future to compile the Linux kernel with VectorC. However, remember that there are currently _no_ compilers other than GCC which can do this (please correct me if I am wrong), as the kernel source uses a number of GCC-specific extensions to C.
It will already compile some other large pieces of software; I myself have used it to compile MAME, and it gave a significant speedup on most games over compiling it with Cygwin GCC (all on Win32, obviously).
C++ compilers all have their own name-mangling schemes which makes different compilers fundamentally incompatible....
but it's very difficult to persuade people to switch from g++
For the PS2 version to support C++ this will _have_ to happen, as the default PS2 compiler is gcc/g++. So I'm sure that the compiler will have to be compatible with at least the GNU C++ ABI (probably version 3.0+), and probably also the CodeWarrior C++ ABI as that's also a popular compiler for PS2 development.
Porting that compatibility to a Linux(x86) version shouldn't be a problem, as that's a higher-level problem than the actual code generation.
If there is no free (as in beer) version then how can one decide if the performance benefits are worth the $$$ ?
This page has a freely downloadable demo version, which only compiles 3 functions in a single source file, so that you can at least see if it does better than your current compiler.
However, you should get better performance the more of the code you compile with VectorC, as you can select different calling conventions using MMX, 3DNow or SSE, avoiding switching in and out of those modes between functions (with all the inherent copying in and out of the extended registers).
And although the company (at least one guy from it at aceshardware forums) does not like to promote vectorc for scientific programming it is at least as useful for serious purposes too.
Scientific applications usually need more than single-precision arithmetic, while the vector instructions available in 3D-Now! and SSE are only single-precision. SSE2 has double-precision as well, so it may be more useful on the Pentium4 for scientific applications:)
Games generally aren't so picky about the precision, and so more can be done to optimize without breaking the code.
...which must surely be illegal, as it would be unable to play a disc conforming to the DVD standard
Sorry, but there is no way that players not conforming to the standard are `illegal' in the sense of the law. If they were, then there would be many manufacturers of early DVD players who would be being sued by consumers for non-100%-conforming players, which wouldn't play their discs properly.
But I am getting tired of propping up the bloated performance and software design practices of certain very big software software companies.
Ah, but you are forgetting that their bloat and the faster processors to cope with that means that we can compile our freshly downloaded kernels/glibc/gcc[1] faster than ever before!:)
[damn, and just _after_ I'd bought that new machine... *sigh*]
[1] gcc 3.0.1 is out, btw. See your nearest mirrors for details.
Eg old warhorse like tar now has support for.bz2 files (tar -zI).
I assume you meant tar -j instead of -zI (apparantly there were a couple of different patched versions using -y or -I and so they picked -j in the newest versions intead).
Ok, this is completely a personal opinion and so many of you will disagree. It is not intended as flamebait.
I feel that there _is_ a need for cross-language interoperability, of a standardised nature. However, I think that following Microsofts lead on.NET is just handing the `win' to them by implementing their proprietary standards on basically every other platform (*nix).
For a long time, interfacing languages has been more difficult than I feel necessary, but how can these problems be overcome when some languages support features (such as overloading, functor objects, higher-order functions) when others do not? Do we opt for the lowest common denominator (procedural interface)?
It would be fantastic to simply be able to use _any_ different languages together to create your apps, but how is.NET going to solve this problem?
...had been going into the 2.4.5-ac kernels (at least the sonypi one, not sure about the motioneye patch for the C1 camera), but are nowhere to be seen in the release kernel:( I thought that Alan Cox had merged all of his patches in for this release, or has Linus decided they aren't worthwhile?
*sobs*
Ah well, I'll just have to patch it myself again then, as us Vaio users aren't important enough for Linus (even though he has a C1 himself...)
Are there _blank_ keycaps available for keyboards?
I see that for the Happy Hacker Keyboard they do Dvorak ones, but I was hoping to have a completely blank keyboard... just to freak out anyone who still needs to look at the keyboard when they are typing;)
I have a Palm Vx and it kills the likes of the iPaq as personal organiser.
... handwriting recognition is good and the organiser apps are great.
If you love the Palm apps, but want something
altogether more computer-like as your PDA (ie. an ipaq), then why not have the best of both worlds and run a Palm emulator[1] on it?;)
I admit, that doesn't improve the battery life or the price, but it's more of an upgrade than any of the recent Palms have been...
[1] Only useful link I can find at the moment is http://www2.sis.pitt.edu/~jkabara/pilot-sync/xcopi lot_faq.html
...then check out Arcade Heaven (http://www.arcadeheaven.co.uk), which has a shop in Maidstone, Kent. I haven't bought anything from them personally, but I have heard lots of good stuff about them, and they guarantee their machines, boards etc for 3 months.
I bought a 4-player Gauntlet machine a while ago (not from the above), but I can't remember where from...:( *sound of memory fading in old age*
[Disclaimer : I'm in no way affiliated with Arcade Heaven, etc etc]
Also, rather amusingly, the email and SMS services are remarkably anonymous. Somehow BT didn't think that anyone would possibly want to abuse a service like this to send abusive/joke/whatever SMS or email messages.... No, of course that would never happen.
...as the floppy doesn't work as a standard floppy, and so using a two-disk boot/root setup doesn't work with USB (or PCMCIA) floppy drives. I am currently trying to get around this problem by using the `initrd' feature instead of a normal ramdisk, and then you can get LILO to load the initrd image (compressed, usually) from the floppy. This should work because LILO (as far as I know) uses the BIOS routines to access the floppy, which work up until the kernel tries to initialize the floppy controller, at which point the USB/PCMCIA floppy fails to work anymore...
I guess that the RedHat boot floppy uses this method, but I haven't looked at it recently.
Also, having the USB drivers built into the kernel still doesn't help here, as the ramdisk only loads from a `standard' floppy (please correct me if I'm wrong), while the usb-storage module makes the usb floppy show up as a removable scsi disk.
If you can fit what is needed for a rootdisk onto a floppy uncompressed, then you can disable the ramdisk, and point root at/dev/sda, which is another option.
Slashdot Mirror
Casio already do this on their `wrist camera' watch, so I guess that it makes enough difference to be worthwhile as a power-saving technique.
Digital is the way to go for me.
- chunky
- difficult to lose
- difficult to forget to put it on (arm feels light)
- looks more professional in my tech-job
- can find north in complete darkness (Mmmmm, digital compass)
- ticking sounds keep me awake at night, as they get several thousand times louder when the surroundings are very quiet
- metal wrist bands are available on digital watches as long as you don't cheap out on them
- I like to have the air pressure, temperature and my heart rate instantly available and logged for later recall
I totally agree, writing SIMD assembly for each platform you want your code to run on is waaaay too much effort when you have deadlines to deal with.
I assume that if Snowfox thinks that there are only a dozen instructions for SIMD operations in games programming, then he is sorely mistaken. The PS2 has _loads_ of vector operations, and I find that it's much more productive to have tools which will do that, along with scheduling the resulting vector operations efficiently, for me.
Also, some media processors have literally _hundreds_ of vector instructions, and even remembering which one of those instructions is suitable for a single operation is hard enough to remember! Leave it to the compiler, I say
This isn't a compiler issue, as separation between multiple processors from a single program will need explicit multi-threading or multiple processes -- automatically finding enough parallelism from a single program to acheive this is very much a research topic at present, except for a very few well-tested and simple cases.
The current version already allows this, as far as I know from using it, as to place restrictions on the use of the source code you have written yourself and compiled with VectorC would really be shooting themselves in the foot...
Besides, the idea is that the compiler and generated object files are 100% compatible with what you already have (source code and object files), so there is no need to `program the kernel with it' as the code will be no different to standard C code.
If the gcc-compatibility is up to par, then it should be possible at some time in the future to compile the Linux kernel with VectorC. However, remember that there are currently _no_ compilers other than GCC which can do this (please correct me if I am wrong), as the kernel source uses a number of GCC-specific extensions to C.
It will already compile some other large pieces of software; I myself have used it to compile MAME, and it gave a significant speedup on most games over compiling it with Cygwin GCC (all on Win32, obviously).
For the PS2 version to support C++ this will _have_ to happen, as the default PS2 compiler is gcc/g++. So I'm sure that the compiler will have to be compatible with at least the GNU C++ ABI (probably version 3.0+), and probably also the CodeWarrior C++ ABI as that's also a popular compiler for PS2 development.
Porting that compatibility to a Linux(x86) version shouldn't be a problem, as that's a higher-level problem than the actual code generation.
This page has a freely downloadable demo version, which only compiles 3 functions in a single source file, so that you can at least see if it does better than your current compiler.
However, you should get better performance the more of the code you compile with VectorC, as you can select different calling conventions using MMX, 3DNow or SSE, avoiding switching in and out of those modes between functions (with all the inherent copying in and out of the extended registers).
Scientific applications usually need more than single-precision arithmetic, while the vector instructions available in 3D-Now! and SSE are only single-precision. SSE2 has double-precision as well, so it may be more useful on the Pentium4 for scientific applications
Games generally aren't so picky about the precision, and so more can be done to optimize without breaking the code.
`F', not `B'? I'm pretty sure that's what I mean when I use _my_ middle finger.
:)
...and exchange them for some that work properly.
At only $2500 per gram, it's a steal.
Don't forget that `dating yourself' makes you go blind, so it might not be the colo[u]r combinations after all.
;)
Sorry, but there is no way that players not conforming to the standard are `illegal' in the sense of the law. If they were, then there would be many manufacturers of early DVD players who would be being sued by consumers for non-100%-conforming players, which wouldn't play their discs properly.
Hmmm, consortium-based standards.
Ah, but you are forgetting that their bloat and the faster processors to cope with that means that we can compile our freshly downloaded kernels/glibc/gcc[1] faster than ever before!
[damn, and just _after_ I'd bought that new machine... *sigh*]
[1] gcc 3.0.1 is out, btw. See your nearest mirrors for details.
I assume you meant tar -j instead of -zI (apparantly there were a couple of different patched versions using -y or -I and so they picked -j in the newest versions intead).
OT? Yes. Many apologies. I am bored.
Ok, this is completely a personal opinion and so many of you will disagree. It is not intended as flamebait.
.NET is just handing the `win' to them by implementing their proprietary standards on basically every other platform (*nix).
.NET going to solve this problem?
I feel that there _is_ a need for cross-language interoperability, of a standardised nature. However, I think that following Microsofts lead on
For a long time, interfacing languages has been more difficult than I feel necessary, but how can these problems be overcome when some languages support features (such as overloading, functor objects, higher-order functions) when others do not? Do we opt for the lowest common denominator (procedural interface)?
It would be fantastic to simply be able to use _any_ different languages together to create your apps, but how is
</vent>
...had been going into the 2.4.5-ac kernels (at least the sonypi one, not sure about the motioneye patch for the C1 camera), but are nowhere to be seen in the release kernel :( I thought that Alan Cox had merged all of his patches in for this release, or has Linus decided they aren't worthwhile?
*sobs*
Ah well, I'll just have to patch it myself again then, as us Vaio users aren't important enough for Linus (even though he has a C1 himself...)
Are there _blank_ keycaps available for keyboards?
;)
I see that for the Happy Hacker Keyboard they do Dvorak ones, but I was hoping to have a completely blank keyboard... just to freak out anyone who still needs to look at the keyboard when they are typing
If you love the Palm apps, but want something
altogether more computer-like as your PDA (ie. an ipaq), then why not have the best of both worlds and run a Palm emulator[1] on it?
I admit, that doesn't improve the battery life or the price, but it's more of an upgrade than any of the recent Palms have been...
[1] Only useful link I can find at the moment is http://www2.sis.pitt.edu/~jkabara/pilot-sync/xcop
(Score: -1, Flamebait)
...then check out Arcade Heaven (http://www.arcadeheaven.co.uk), which has a shop in Maidstone, Kent. I haven't bought anything from them personally, but I have heard lots of good stuff about them, and they guarantee their machines, boards etc for 3 months.
:( *sound of memory fading in old age*
I bought a 4-player Gauntlet machine a while ago (not from the above), but I can't remember where from...
[Disclaimer : I'm in no way affiliated with Arcade Heaven, etc etc]
Also, rather amusingly, the email and SMS services are remarkably anonymous. Somehow BT didn't think that anyone would possibly want to abuse a service like this to send abusive/joke/whatever SMS or email messages.... No, of course that would never happen.
Are they completely stupid, or just braindead?
That was an obvious typo. I'm sure he meant that it is bazaar.
;)
...as the floppy doesn't work as a standard floppy, and so using a two-disk boot/root setup doesn't work with USB (or PCMCIA) floppy drives. I am currently trying to get around this problem by using the `initrd' feature instead of a normal ramdisk, and then you can get LILO to load the initrd image (compressed, usually) from the floppy. This should work because LILO (as far as I know) uses the BIOS routines to access the floppy, which work up until the kernel tries to initialize the floppy controller, at which point the USB/PCMCIA floppy fails to work anymore...
/dev/sda, which is another option.
I guess that the RedHat boot floppy uses this method, but I haven't looked at it recently.
Also, having the USB drivers built into the kernel still doesn't help here, as the ramdisk only loads from a `standard' floppy (please correct me if I'm wrong), while the usb-storage module makes the usb floppy show up as a removable scsi disk.
If you can fit what is needed for a rootdisk onto a floppy uncompressed, then you can disable the ramdisk, and point root at
Jim isn't going to be able to do anything about the `threat' because he's all chin and no trousers.
;)
Sony and Philips have already done a double-density 1©3Gb format, although I'm not sure if there are actually any products which use the format yet©
It was reported on Slashdot a while ago ¥I can't find it in the older stuff though, and you can read about it on the CDR-Info site©
I also think that the reason it hasn't done well is pretty obvious, and that's because just double ¥or 4x the capacity isn't enough for some people, and it still involves buying a new drive and media which will be obseleted as soon as DVD-R/DVD-RW/DVD+RW/DVD-flavour-of-the-month becomes cheap enough to be more viable as a backup method©