Wow, I'm almost the same way. I started learning German at 14 (not by immersion) Now, after 10 years, I went to Germany, and had the ability to speak and understand people well enough, but it took me a whole day to digest and accept spoken German as a language.
4 years after begining to learn German, I started learning Japanese. It was very easy to grasp the grammar. While Japanese is usually taught by "patterns" to Americans, I was able to identify the more complex structures underlying everything rather than just rout memorization of patterns.
Of course, the cool thing was that the Japanese teacher was saying, (with a very bad Japanese accent) "It's very hard for Americans to pronounce the tsu syllable." Then she looks at me, and I'm like "what? tsu. Christ, in German they have ts starting more phomenes than just u"
I also started learning Esperanto at around age 15 or 16, and basicly, I just picked up learning languages as a hobby. Now, I can run through languages learning the basics and perhaps a bit more in just a few weeks. If they're very related to a language I already know well, then even shorter. (I learned Swedish to a conversational level in about a week, to a month.)
Ah, but has anyone noticed that the Slashdot article contains THREE DIFFERENT IP GROUPS in it?
First, the title says "expired TRADEMARK", the article takes about the DHS enforcing COPYRIGHTS, then lastly it mentions that the PATENT for the rubik's cube is already expired.
So, like... did anyone bother to go over this and at least make sure that the article was at least talking consistantly about the specific IP protection being applied here?
Ockham's Razor states "do not create entities unnecessarily", not that the simplest explination is best.
In fact, a simpler explaination of heat would be that there are heat molecules that are passed from one object to the other.
Ockham's Razor eliminates this because you're making an entity from thin air, without having observed them, and that an existing theory explains the observed phenomena without the need for creating a heat particle.
I use this same reason to refuse the belief in a graviton until it is shown that it must exist, and that the only explanation available which account for the observed phenomena requires them.
Yes, well, as one of the major developers of PearPC, I'd think he'd like to have my name and address. So he knows where to send any apologies that might occur to him to be necessary.
It is humorous. Because it's definately not accurate. The processor time spent on PearPC is for EVERYTHING that PearPC does. Including applications, hardware devices... EVERYTHING.
So, please reread the post, and understand the joke.
Maybe you should go and get some experience or at least some knowledge before you start talking about something you know nothing about.
If _ANYONE_ says this to my post, I'm going to hurt them. And hurt them hard.
First of all, it's not relatively all that hard to mimic the AltiVec instructions using SSE/SSE2/SSE3.
Secondly, the majority of operations done by many AltiVec instructions use a limited number of AltiVec registers. The ones that do use the significant number of registers are things like matrix operations, complex mathematics, and bioinformatics type things.
Next up, AltiVec is very well behaved. It does not perform any accesses on anything but 16-bit alligned addresses. If you access some value (x4)+y it will access the 128-bit vector starting at address (x4). This means that one can avoid all the horrible nastiness of emulating cross-page accesses. They're all well defined.
Also, AltiVec produces little side-effects (the only exception that the non-load AltiVec instructions effect is if the MSR_VEC bit is not set) and no condition code changes (except for the vcmp* instructions)
All of this adds up to that there are numerous benifits to implementing the AltiVec instructions in SSE, or even in just normal "scalar" code. This is because you can make the individual instructions much more efficient than those that require the overhead of the regular engine.
Overall, it's hard to really say that there is much of a benifit. There are a lot of things that fall into the "overhead" section, of just matching the instructions to x86 code that does the exact same thing. But there's also a lot of benifit that comes from it.
PearPC is making good progress in this regard.:P
First, let me start by saying. Look at PearPC AltiVec branch. We have a working AltiVec implementation in PearPC, and in the JITC core it is using SSE code (there's no SSE2 support, as I don't have the hardware at this time to test it)
Second of all. It would be relatively easy to emulate SSE, SSE2 and SSE3 on a G5. The only issue would be that you'd have to play with the double precision float versions of the SSE instructions. But that's not a big deal. The G5 can issue two floating point instructions during one cycle (PowerPC does all floating point math in double precision) so you get the same effect anyways.
BTW, it's virtually useless to implement a double precision 128-bit vector. A two element vector won't gain you much in terms of parallelizabilty once you add the vectorization overhead.
Oh, and on the last point. New information straight from the words of a Pentium 3/4/M optimization manual. It is faster to perform an MMX operation than an XMM (SSE/SSE2/SSE3) instruction. Because "they're wider"
I leave it as a problem for the reader why Intel wouldn't make it just as fast, when it's just as parallelizable.
OpenFirmware is entirely architecture independant. The drivers and everything are written in either Forth code, or FCode (a bytecode like format for the Forth code)
This means that it can use ANY architecture. Sun Microsystems uses OpenFirmware as much as Apple, and are one of the major parties to the OpenFirmware standards.
Likewise, the OpenBIOS program is working on making a standardized OpenFirmware implementation that will run even on x86 hardware.
The G4, and the G5 definately have rename registers.
But very true, the PearPC compiler can't address any of these extra registers at all. I've been thinking about working on something that would allow PearPC to reorder the instructions to attempt to reduce some of the overhead of swapping out registers and such.
PearPC has not jitc_x86_64 core yet. The only way to use the full x86-64 bit performance would be to compile using the generic core. And guess what? That's the snails pace version.
You're better off compiling an ia32 binary with the jitc_x86 core rather than generic core with the x86-64 settings.
But we expect that using the x86-64 for the jitc would definately help.
The problem wouldn't be making a work around, the problem would be including Apple's copyright phrase into the program.
Putting "Copyright... Apple" would just not be a good idea by anyone's definition.
Plus, it could be seen as circumventing copyright protection, (as that's exactly what would be being done) and thus, could lead to my prosecution under the DMCA.
Very true... I wouldn't expect it to hold up in any court.
But of course, Sega v. Accolade protected reverse engineering.
Of course, there's nothing that Apple can do against PearPC itself, because it's built toward the open hardware standards that are freely available on the internet.
I've worked through some code to get OS9 to boot on PearPC, but unfortunately, it drops the error that the Apple Copyright isn't found.
Of course, working around THAT would be illegal by any definition that I know of. So, for the moment, PearPC will not be booting OS9 anytime soon.
"That is like me telling people I got my Xbox to play SNES Games when all I am really doing is pulling up an SNES emulator on my xbox with Linux."
So, your X-Box _WOULD_ be playing SNES games. Are you confused as to exactly how emulation works?
Re:They skirted around 1 legality when they wrote
on
Mac OS X Running On Xbox
·
· Score: 2, Interesting
It's actually Apple _LABELLED_ hardware. Technically, I think it might be possible to get around that by slapping an official Apple logo from Apple on the piece of hardware.
Apple has yet to respond to PearPC at all so far. We'll deal with it when it arrives, then we'll remind them that we didn't do anything but build our emulator toward the documented standards that are freely available on the internet.
P3-800MHz even running the generic core only took about a half hour to boot.
I know this metric well, because I kept having to boot it in order to test my AltiVec code. Now, imagine having to wait 30 minutes to see if what you "fixed" in your code made any difference.
I have a read Mac, and I'm still one of the developers of PearPC.
I don't do it because I expect it to replace a real Mac, but rather because I like emulation.
On the other hand, we have a lot of people who would like to try MacOSX out, and see what all the fuss is about, before they drop 2 grand on something they might hate.
PearPC fills nicely for this. Many of our users talk about how they're going to save up, and buy a real Mac now.
But PearPC has enormous overhead beyond the virtual memory itself. Not only the available memory for PearPC, but also the resident code pages for PearPC, and then also the resident code pages for the JITC emulation.
So, even if the box had 128MiB of RAM, it's still going to be thrashing hard.
Well, with Apple it's obvious. They say in their EULA that you bought their CD, but not the software on it. You thus own the CD, and physical material and can do what ever you want with it... as long as it doesn't infringe on the softare's EULA agreement to install it on one (1) Apple labelled computer.
These children produced a signifcant language with real syntax and grammar.
As of yet, the best animals have accomplished is at best a pidgin, which has limited to no grammatical structure and form.
Read Steve Pinker's "The Language Instinct" he covers Noam Chimpsky, which was a very strong and (reasonably) successful chimp who learned sign language.
The best he learned was pidgin like structure, and the single native sign language speaker continued to turn in signficantly fewer signs that the chimp signed than everyone else turned it.
Slashdot Mirror
Yeah, I know... I just thought I'd Karma whore some by stating the obvious closer to the top than the last time it was mentioned...
Wow, I'm almost the same way. I started learning German at 14 (not by immersion) Now, after 10 years, I went to Germany, and had the ability to speak and understand people well enough, but it took me a whole day to digest and accept spoken German as a language.
4 years after begining to learn German, I started learning Japanese. It was very easy to grasp the grammar. While Japanese is usually taught by "patterns" to Americans, I was able to identify the more complex structures underlying everything rather than just rout memorization of patterns.
Of course, the cool thing was that the Japanese teacher was saying, (with a very bad Japanese accent) "It's very hard for Americans to pronounce the tsu syllable." Then she looks at me, and I'm like "what? tsu. Christ, in German they have ts starting more phomenes than just u"
I also started learning Esperanto at around age 15 or 16, and basicly, I just picked up learning languages as a hobby. Now, I can run through languages learning the basics and perhaps a bit more in just a few weeks. If they're very related to a language I already know well, then even shorter. (I learned Swedish to a conversational level in about a week, to a month.)
Ah, but has anyone noticed that the Slashdot article contains THREE DIFFERENT IP GROUPS in it?
First, the title says "expired TRADEMARK", the article takes about the DHS enforcing COPYRIGHTS, then lastly it mentions that the PATENT for the rubik's cube is already expired.
So, like... did anyone bother to go over this and at least make sure that the article was at least talking consistantly about the specific IP protection being applied here?
(Going off information from my Japanese class)
Worse is Japan, where usually in a department store they have a greeter at EVERY FLOOR.
Usually, it's some sort of woman, and they're always shouting "irrashaimasu!" at you.
People say it's annoying, but they leave the area and come back to the US, and they feel it hauntingly missing.
No, as far as I'm aware, PearPC still does not emulate a multi-button mouse.
Ockham's Razor states "do not create entities unnecessarily", not that the simplest explination is best.
In fact, a simpler explaination of heat would be that there are heat molecules that are passed from one object to the other.
Ockham's Razor eliminates this because you're making an entity from thin air, without having observed them, and that an existing theory explains the observed phenomena without the need for creating a heat particle.
I use this same reason to refuse the belief in a graviton until it is shown that it must exist, and that the only explanation available which account for the observed phenomena requires them.
Yes, well, as one of the major developers of PearPC, I'd think he'd like to have my name and address. So he knows where to send any apologies that might occur to him to be necessary.
You forgot the "Both ways!"
It is humorous. Because it's definately not accurate. The processor time spent on PearPC is for EVERYTHING that PearPC does. Including applications, hardware devices... EVERYTHING.
So, please reread the post, and understand the joke.
Maybe you should go and get some experience or at least some knowledge before you start talking about something you know nothing about. If _ANYONE_ says this to my post, I'm going to hurt them. And hurt them hard. First of all, it's not relatively all that hard to mimic the AltiVec instructions using SSE/SSE2/SSE3. Secondly, the majority of operations done by many AltiVec instructions use a limited number of AltiVec registers. The ones that do use the significant number of registers are things like matrix operations, complex mathematics, and bioinformatics type things. Next up, AltiVec is very well behaved. It does not perform any accesses on anything but 16-bit alligned addresses. If you access some value (x4)+y it will access the 128-bit vector starting at address (x4). This means that one can avoid all the horrible nastiness of emulating cross-page accesses. They're all well defined. Also, AltiVec produces little side-effects (the only exception that the non-load AltiVec instructions effect is if the MSR_VEC bit is not set) and no condition code changes (except for the vcmp* instructions) All of this adds up to that there are numerous benifits to implementing the AltiVec instructions in SSE, or even in just normal "scalar" code. This is because you can make the individual instructions much more efficient than those that require the overhead of the regular engine. Overall, it's hard to really say that there is much of a benifit. There are a lot of things that fall into the "overhead" section, of just matching the instructions to x86 code that does the exact same thing. But there's also a lot of benifit that comes from it. PearPC is making good progress in this regard. :P
First, let me start by saying. Look at PearPC AltiVec branch. We have a working AltiVec implementation in PearPC, and in the JITC core it is using SSE code (there's no SSE2 support, as I don't have the hardware at this time to test it)
Second of all. It would be relatively easy to emulate SSE, SSE2 and SSE3 on a G5. The only issue would be that you'd have to play with the double precision float versions of the SSE instructions. But that's not a big deal. The G5 can issue two floating point instructions during one cycle (PowerPC does all floating point math in double precision) so you get the same effect anyways.
BTW, it's virtually useless to implement a double precision 128-bit vector. A two element vector won't gain you much in terms of parallelizabilty once you add the vectorization overhead.
Oh, and on the last point. New information straight from the words of a Pentium 3/4/M optimization manual. It is faster to perform an MMX operation than an XMM (SSE/SSE2/SSE3) instruction. Because "they're wider"
I leave it as a problem for the reader why Intel wouldn't make it just as fast, when it's just as parallelizable.
OpenFirmware is entirely architecture independant. The drivers and everything are written in either Forth code, or FCode (a bytecode like format for the Forth code)
This means that it can use ANY architecture. Sun Microsystems uses OpenFirmware as much as Apple, and are one of the major parties to the OpenFirmware standards.
Likewise, the OpenBIOS program is working on making a standardized OpenFirmware implementation that will run even on x86 hardware.
The G4, and the G5 definately have rename registers.
But very true, the PearPC compiler can't address any of these extra registers at all. I've been thinking about working on something that would allow PearPC to reorder the instructions to attempt to reduce some of the overhead of swapping out registers and such.
But I don't expect this to happen anytime soon.
PearPC has not jitc_x86_64 core yet. The only way to use the full x86-64 bit performance would be to compile using the generic core. And guess what? That's the snails pace version.
You're better off compiling an ia32 binary with the jitc_x86 core rather than generic core with the x86-64 settings.
But we expect that using the x86-64 for the jitc would definately help.
The problem wouldn't be making a work around, the problem would be including Apple's copyright phrase into the program.
:(
Putting "Copyright... Apple" would just not be a good idea by anyone's definition.
Plus, it could be seen as circumventing copyright protection, (as that's exactly what would be being done) and thus, could lead to my prosecution under the DMCA.
Damn the DMCA...
In this hypothetical environment of which I'm speaking of... yes.
*shifty eyes* Maybe...
Very true... I wouldn't expect it to hold up in any court.
But of course, Sega v. Accolade protected reverse engineering.
Of course, there's nothing that Apple can do against PearPC itself, because it's built toward the open hardware standards that are freely available on the internet.
I've worked through some code to get OS9 to boot on PearPC, but unfortunately, it drops the error that the Apple Copyright isn't found.
Of course, working around THAT would be illegal by any definition that I know of. So, for the moment, PearPC will not be booting OS9 anytime soon.
"That is like me telling people I got my Xbox to play SNES Games when all I am really doing is pulling up an SNES emulator on my xbox with Linux."
So, your X-Box _WOULD_ be playing SNES games. Are you confused as to exactly how emulation works?
It's actually Apple _LABELLED_ hardware. Technically, I think it might be possible to get around that by slapping an official Apple logo from Apple on the piece of hardware.
Apple has yet to respond to PearPC at all so far. We'll deal with it when it arrives, then we'll remind them that we didn't do anything but build our emulator toward the documented standards that are freely available on the internet.
P3-800MHz even running the generic core only took about a half hour to boot.
I know this metric well, because I kept having to boot it in order to test my AltiVec code. Now, imagine having to wait 30 minutes to see if what you "fixed" in your code made any difference.
I have a read Mac, and I'm still one of the developers of PearPC.
I don't do it because I expect it to replace a real Mac, but rather because I like emulation.
On the other hand, we have a lot of people who would like to try MacOSX out, and see what all the fuss is about, before they drop 2 grand on something they might hate.
PearPC fills nicely for this. Many of our users talk about how they're going to save up, and buy a real Mac now.
Speed has almost no factor in this. First, it was just a demonstration of the capability.
Just the fact that someone did it is cool. It's like Sputnik. It went up, it sent back "beep beep beep", and the whole world held its breath.
Whether it's slow or not, the fact that someone did it is just sweet.
But PearPC has enormous overhead beyond the virtual memory itself. Not only the available memory for PearPC, but also the resident code pages for PearPC, and then also the resident code pages for the JITC emulation.
So, even if the box had 128MiB of RAM, it's still going to be thrashing hard.
It's still COOL though.
Well, with Apple it's obvious. They say in their EULA that you bought their CD, but not the software on it. You thus own the CD, and physical material and can do what ever you want with it... as long as it doesn't infringe on the softare's EULA agreement to install it on one (1) Apple labelled computer.
These children produced a signifcant language with real syntax and grammar.
As of yet, the best animals have accomplished is at best a pidgin, which has limited to no grammatical structure and form.
Read Steve Pinker's "The Language Instinct" he covers Noam Chimpsky, which was a very strong and (reasonably) successful chimp who learned sign language.
The best he learned was pidgin like structure, and the single native sign language speaker continued to turn in signficantly fewer signs that the chimp signed than everyone else turned it.