I haven't done work on the IA64 yet, but I have done work with a software pipelined DSP, the TI TMS320C6701. I found out the following things about compilers for such beasts:
1) The compilers are MUCH more complex and therefore have complex bugs when compiling complex loops
2) C/C++ are not good enough languages to express enough hints to the compiler to allow it to optimize properly.
3) Therefore, C/C++ require non-portable language extensions for these hints.
4) Advanced usage of C++ inline templates CAN help, but are still not as flexible as you want in terms of allowing the best re-ordering of code possible.
For example, you HAVE to use the new 'restrict' keyword to give the compiler hints about un-aliased pointers. pragmas or similiar hacks are required to give the compiler hints about how many times a loop will be executed - for example, telling the compiler that although a loop is repeated based on a separate run-time variable or parameter, it is guaranteed to never be 0 and will always be a multiple of 8 loops. That kind of thing allows the compiler to really do a good job on the loops - but is not part of the C/C++ standards.
In my opinion, C and C++ are too 'low level' and restrictive in terms of allowing the compiler to re-order the code to be really effective on non-typical architectures like these. Unfortunately there doesn't seem to be any other options. I would expect that a functional language like OCaml would allow the compiler much more freedom to do a better job - Once there is real support in OCaml for the ia64....
Also, I highly doubt that GCC is going to be the best or even a very good compiler for ia64 for some time. I'll be happy if i'm wrong though!
My opinion is that you did the right thing by diving into the assembly.
Also, XOR is bad to use. Stay away from it. A sequence of 0's in the key and there will be cleartext coming through. So you need a more complex function that depends on the result of the previous byte encryption. Then, to get around the gzip header problem, you prefix your file with a random number of bytes of true random data. The header will be completely obfuscated then.
But this is all moot, and has been thought of before. I'm sure that the amazing wizard geniuses who figured out the binary digit pi calculation could crack a simple minded pi-based encryption algorithm faster than you can understand their equation! Read their papers for their description of how they found their equation and most people will be lost in the first paragraph.
Regardless, all PI based encryption algorithms will be secret-key encryption, which is not nearly as useful as public key encryption.
Interesting thing though, I wrote the (crappy) win 3.1 software for N.E.C.'s PC-VCR, 10 years ago. It was a really neat SVHS VCR with a RS-232 port, and almost frame accurate proprietary time code. The example unix commands in my previous comment would have been easier to manage than the very cryptic and buggy RS-232 command set that NEC provided in the PC-VCR.
The concept of ethernet accessible appliances IS usually a good one and I am impressed that Rogers is trying to go down this road. As long as they don't forget about security!
yes! And now there will be no excuse for gramma and grampa to have the continuous flashing 12:00 on their VCR! All they would have to do is know the following:
$ telnet jvc_vcr
$ date -s "Wed Jun 20 13:20:41 PDT 2001"
And then if they wanted to auto record a tv show tonight at 9:00 pm, instead of all the confusing menus, all they have to do is:
$ telnet jvc_vcr
$ at 21:00
at> set channel=9
at> set mode=record
warning: commands will be executed using/bin/sh
job 8 at 2001-06-20 21:00
$ at 22:00
at> set mode=stop
warning: commands will be executed using/bin/sh
job 9 at 2001-06-20 22:00
AND, if they wanted to record their faourite show every week they could very easily do:
Weren't at least the original southparks done in Shockwave or Flash? I'm certain that those files would be smaller than an mpeg of the video. If they had all the episodes in flash they would probably fit on one DVD. So there is still more that MPEG could do. Knowing more about the type of data to compress allows for better compression.
MPEG should come up with a new level of compression especially geared towards cartoons. I'm sure that animations like South Park and The Simpsons could compress really really small and still be top quality images with the proper algorithm. THEN, we could fit an entire season of episodes on ONE DVD!
I've seen two laptops with active matrix displays that had to be replaced within 2 years simply because the backlight faded to be very dim. Strange that they were enclosed in such a way that the whole LCD had to be replaced.
Well, it is meaningless to compare altivec g4 versus non-altivec PIII. But it is not meaningless to compare non-altivec-non-mmx g4 versus non-altivec-non-mmx PIII.
It would be meaningful to compare altivec g4 versus MMX PIII. I would be interested to see the results. Anyone know MMX?
I wrote that benchmark in order to qualify using the G4 in an embedded system specifically made for handling massive amounts (>400) of real time audio channels at 48 KHz.
The benchmark shows that the number of usable single precision megaflops PER WATT OF POWER DISSIPATION and PER DOLLAR for the CPU is much much higher on the G4.
The algorithm in the benchmark is the EXACT algorithm that I used in various DSP's in real products. It is not a synthetic test. The G4 beats the DSPs and all other CPU's that may have been an option for the embedded system. That is what is important to me.
For what I do with massive digital audio processing, single precision floating point is exactly perfect. 24 bit A/D-D/A converter maps nicely to a 32 bit float.
Sorry, I don't think the G4 is a good deal in terms of cost/performance. You pay a premium for Apple; that may
be worth it for other reasons, but not because of performance.
Hmmm... This is something that the Quebecois 'Language Police' should be focussing on, instead of just wasting time charging businesses who have non-french signage.
If you don't want any worm-style program doing anything to your machines, then you as an administrator who 'knows every damn single thing that is done to the machine' will make the machine secure so this worm won't bother you.
It will only bother you if you don't do your job properly.
At least this worm will (apparently) close some holes on the machines where the owners are silly and say things like 'Who would care about my data? There is nothing important on that computer so I do not need to secure it.'
I've had people tell me that "Satan put all the apparent evidence that the world is older than 6000 years. God looks at the whole thing as a test of your faith."
Some people (Not just creationists) will believe what they believe, no matter how much evidence there is for or against their beliefs.
Now, what I WANT is a Python that fits in 16K bytes. If basic was possible in 4K, why not?
Funny thing is that I was JUST thinking about how tight the old basic interpreters were (apple II, II+). I'd like to use something like python in very tiny embedded controllers.
It would be neat to have docs in XML, and have a version control system that understood xml. Then the version control system can produce valid xml output for the diffs.
I'm only partially joking however. That would be SO NICE.
Regardless, CVS handles binaries (albeit inefficiently) and isn't that hard to use with wincvs.
The point is to not spend time adding features that 'you think you might need in the future'. In the future you will find that either you did need the feature, but your design or implementation of it was broken or you didn't need the feature and now you have bloat.
Read up more on XP. Skipping ground work is not the idea of XP. Providing the tested, working features that the customer actually needs is.
Code re-use across different projects with different requirements in normal life does not always turn out well anyways.
'Darn there is no way to implement that feature like the customer needs without changing the design of our supposedly reusable library!'
The point is that you can't know that until you get there.
Slashdot Mirror
I haven't done work on the IA64 yet, but I have done work with a software pipelined DSP, the TI TMS320C6701. I found out the following things about compilers for such beasts:
1) The compilers are MUCH more complex and therefore have complex bugs when compiling complex loops
2) C/C++ are not good enough languages to express enough hints to the compiler to allow it to optimize properly.
3) Therefore, C/C++ require non-portable language extensions for these hints.
4) Advanced usage of C++ inline templates CAN help, but are still not as flexible as you want in terms of allowing the best re-ordering of code possible.
For example, you HAVE to use the new 'restrict' keyword to give the compiler hints about un-aliased pointers. pragmas or similiar hacks are required to give the compiler hints about how many times a loop will be executed - for example, telling the compiler that although a loop is repeated based on a separate run-time variable or parameter, it is guaranteed to never be 0 and will always be a multiple of 8 loops. That kind of thing allows the compiler to really do a good job on the loops - but is not part of the C/C++ standards.
In my opinion, C and C++ are too 'low level' and restrictive in terms of allowing the compiler to re-order the code to be really effective on non-typical architectures like these. Unfortunately there doesn't seem to be any other options. I would expect that a functional language like OCaml would allow the compiler much more freedom to do a better job - Once there is real support in OCaml for the ia64....
Also, I highly doubt that GCC is going to be the best or even a very good compiler for ia64 for some time. I'll be happy if i'm wrong though!
My opinion is that you did the right thing by diving into the assembly.
--jeff
Also, XOR is bad to use. Stay away from it. A sequence of 0's in the key and there will be cleartext coming through. So you need a more complex function that depends on the result of the previous byte encryption. Then, to get around the gzip header problem, you prefix your file with a random number of bytes of true random data. The header will be completely obfuscated then.
But this is all moot, and has been thought of before. I'm sure that the amazing wizard geniuses who figured out the binary digit pi calculation could crack a simple minded pi-based encryption algorithm faster than you can understand their equation! Read their papers for their description of how they found their equation and most people will be lost in the first paragraph.
Regardless, all PI based encryption algorithms will be secret-key encryption, which is not nearly as useful as public key encryption.
--jeff
Take a look at SFU's "Inverse Symbolic Calculator" which is pretty awesome.
http://www.cecm.sfu.ca/projects/ISC/
Oh, absolutely! It was just a joke.
Interesting thing though, I wrote the (crappy) win 3.1 software for N.E.C.'s PC-VCR, 10 years ago. It was a really neat SVHS VCR with a RS-232 port, and almost frame accurate proprietary time code. The example unix commands in my previous comment would have been easier to manage than the very cryptic and buggy RS-232 command set that NEC provided in the PC-VCR.
The concept of ethernet accessible appliances IS usually a good one and I am impressed that Rogers is trying to go down this road. As long as they don't forget about security!
--jeff
yes! And now there will be no excuse for gramma and grampa to have the continuous flashing 12:00 on their VCR! All they would have to do is know the following:
/bin/sh
/bin/sh
/usr/bin/vcrrecord 3
/usr/bin/vcrstoprecord 3
$ telnet jvc_vcr
$ date -s "Wed Jun 20 13:20:41 PDT 2001"
And then if they wanted to auto record a tv show tonight at 9:00 pm, instead of all the confusing menus, all they have to do is:
$ telnet jvc_vcr
$ at 21:00
at> set channel=9
at> set mode=record
warning: commands will be executed using
job 8 at 2001-06-20 21:00
$ at 22:00
at> set mode=stop
warning: commands will be executed using
job 9 at 2001-06-20 22:00
AND, if they wanted to record their faourite show every week they could very easily do:
$ crontab -e
0 21 * * 3 viewer
0 22 * * 3 viewer
Hey, I think I'm on to something! (crack maybe?)
--jeff
The (almost) ultimate test of a c++ compiler with templates is the blitz++ library at http://www.oonumerics.org/blitz/
I wonder how well it works with g++ 3.0?
--jeff
Weren't at least the original southparks done in Shockwave or Flash? I'm certain that those files would be smaller than an mpeg of the video. If they had all the episodes in flash they would probably fit on one DVD. So there is still more that MPEG could do. Knowing more about the type of data to compress allows for better compression.
--jeff
MPEG should come up with a new level of compression especially geared towards cartoons. I'm sure that animations like South Park and The Simpsons could compress really really small and still be top quality images with the proper algorithm. THEN, we could fit an entire season of episodes on ONE DVD!
I've seen two laptops with active matrix displays that had to be replaced within 2 years simply because the backlight faded to be very dim. Strange that they were enclosed in such a way that the whole LCD had to be replaced.
--jeff
Feel free to email me! I'm interested.
Well, it is meaningless to compare altivec g4 versus non-altivec PIII. But it is not meaningless to compare non-altivec-non-mmx g4 versus non-altivec-non-mmx PIII.
It would be meaningful to compare altivec g4 versus MMX PIII. I would be interested to see the results. Anyone know MMX?
--jeff
Hey, it is GPL'd, go for it! Add it yourself! --jeff
I wrote that benchmark in order to qualify using the G4 in an embedded system specifically made for handling massive amounts (>400) of real time audio channels at 48 KHz.
The benchmark shows that the number of usable single precision megaflops PER WATT OF POWER DISSIPATION and PER DOLLAR for the CPU is much much higher on the G4.
The algorithm in the benchmark is the EXACT algorithm that I used in various DSP's in real products. It is not a synthetic test. The G4 beats the DSPs and all other CPU's that may have been an option for the embedded system. That is what is important to me.
--jeff
For what I do with massive digital audio processing, single precision floating point is exactly perfect. 24 bit A/D-D/A converter maps nicely to a 32 bit float.
--jeff
Yes, I agree
--jeff
http://www.jdkoftinoff.com/eqtest.tar.gz
(gpl'd with source)
450 mhz g4:
1.7 gigaflops with altivec
410 megaflops without altivec
500 mhz pentium:
220 megaflops
--jeff
Hmmm... This is something that the Quebecois 'Language Police' should be focussing on, instead of just wasting time charging businesses who have non-french signage.
--jeff
If you don't want any worm-style program doing anything to your machines, then you as an administrator who 'knows every damn single thing that is done to the machine' will make the machine secure so this worm won't bother you.
It will only bother you if you don't do your job properly.
At least this worm will (apparently) close some holes on the machines where the owners are silly and say things like 'Who would care about my data? There is nothing important on that computer so I do not need to secure it.'
--jeff
You do not understand.
I've had people tell me that "Satan put all the apparent evidence that the world is older than 6000 years. God looks at the whole thing as a test of your faith."
Some people (Not just creationists) will believe what they believe, no matter how much evidence there is for or against their beliefs.
Stop trying.
--jeff
Interesting that he likes Python.
Now, what I WANT is a Python that fits in 16K bytes. If basic was possible in 4K, why not?
Funny thing is that I was JUST thinking about how tight the old basic interpreters were (apple II, II+). I'd like to use something like python in very tiny embedded controllers.
--jeff
Good points.
It would be neat to have docs in XML, and have a version control system that understood xml. Then the version control system can produce valid xml output for the diffs.
--jeff
1) Switch to LaTeX
2) Teach them CVS
haha!
I'm only partially joking however. That would be SO NICE.
Regardless, CVS handles binaries (albeit inefficiently) and isn't that hard to use with wincvs.
--jeff
Absolutely!
UPS has already sued Canada Post because Canada Post is cheaper and partially government funded.
--jeff
You can NOT release something under one license and then retroactively change the license.
IF freedb copied cddb's database when cddb's DATA was released under the GPL, then cddb can not pull this stunt.
Imagine if Linus said "Oh I'm gonna retroactively change the license for linux to be huge $ now, so everyone who used linux 8 years ago, pay up!"
However if freedb copied their database after cddb changed the data's license, then freedb is in the wrong.
--jeff
The point is to not spend time adding features that 'you think you might need in the future'. In the future you will find that either you did need the feature, but your design or implementation of it was broken or you didn't need the feature and now you have bloat.
Read up more on XP. Skipping ground work is not the idea of XP. Providing the tested, working features that the customer actually needs is.
Code re-use across different projects with different requirements in normal life does not always turn out well anyways.
'Darn there is no way to implement that feature like the customer needs without changing the design of our supposedly reusable library!'
The point is that you can't know that until you get there.
--jeff