How can a JIT run faster than a Jazelle implimentation?
The same reason ARM code is faster than THUMB. When you compile an algorithm to a bytecode, it probably takes more instructions than it would take using 32-bit ARM instructions. When you JIT you don't just convert a bytecode to an ARM instruction, you do some optimization, and the resulting code is typically faster.
There are also other optimizations you can do at execution time that you just can't do at compile time. This is why work you do in the microarchitecture pays off (ie, out of order execution, alias detection, etc), but you can also find interesting things like HP Dynamo that find speedups in JIT recompiling PA-RISC to PA-RISC. Fun read, check it out. Ars technica article here, real paper here
I don't think they're implemented by microcoding, but rather with a pipeline stage that stalls for multiple cycles
On most ARM implementations, it's a state machine that dispatches multiple load operations... and because you can write the program counter like a normal register you can get branch functionality at the same time. It's crazy. Anyway, in my opinion, if you have to have a state machine to turn one instruction magically into many instructions it doesn't meet the "RISC philosophy" of having simple instructions that just shoot down the pipeline.
But RISC is just a word, and different people believe different things. I know folks who think that RISC means "an instrucion set with few instructions." In reality, things are just shades of grey, with (I guess) MIPS being on one end and oh, maybe x86 or VAX on the other.
It's because if you're willing to throw some effort at the problem, the instruction set doesn't matter.
Intel chips haven't really executed x86 since the original Pentium. They translate the instructions into a more convienient form and execute those. They do analysis in hardware and find all sorts of opportunities to make code run faster.
As it turns out, you have to do most of the same analysis to get good performance on a RISC too. So you have a bit of extra decoding work, which you might not have to do on a MIPS or something, but you gain some flexibility in what lies underneath. And if you're producing 10x the amount of processors as Freescale, you're going to be able to make up for any marginal increase in cost the extra complexity costs you.
Also, don't buy into the hype. You can't buy that much from a good ISA on high-end processors. Look at the SPEC numbers for the Core 2 duo vs. anyone else if you don't believe me. IA64 was supposed to be the greatest thing ever because compilers could do all the work at compile time. There's almost every instruction set hook imaginable in IA64. And look how that architecture has turned out.
We use x86 because instruction translation is pretty easy and very effective... the same reason why Java algorithms perform pretty well, Transmeta had a halfway decent chip, Alpha could execute x86 code pretty well, and Apple can run PPC apps pretty well on x86. It's not bad enough to be completely broken, and we can engineer our way out of the problems in the architecture.
Of course, if you're counting transistors and joules, some of this breaks down... that's why ARM and DSPs have been effective at the low end.
Someone should tell that to the US Government. Maybe I can get my senator and congressperson arrested. If I set up a program where you got paied by 10 other people who had the "promise" of getting paied later on, I'd get arreseted.
Anyway, if our government can't be fiscally responsible (or even fiscally ethical) in its programs, how can it expect to have moral authority over real life financial scams, much less ones in video games?
The Shannon Limit shows that you can get datarates up to B*log2(1+(S/N)), where B is (spectrum) bandwidth, S is singal level, and N is noise level.
If the SNR is very high and so is the bandwitdth, you can transmit a lot of data. We could already do that with things like optical and electrical cables, microwave links, etc.
Some features of a wireless link can help you improve SNR. For instance, you can use things like rake receivers to reduce multipath interference. But you're never going to do all that well in a building, in a city, with tons of EMF interference from all sorts of things, with a single, tiny, omnidirectional antenna. Especially if you want your mobile device to work when you start moving around at 200kph.
So if you have a big, fixed, maybe directional antenna with line-of-site to the basestation, and you've allocated a large chunk of spectrum, it's easy to get a high datarate. WiMax doesn't help you all that much, some of the OFDM tricks it uses help out some but is fundamentally it's not all that much better than anything we already have. For example, you hook up 802.11g through high-SNR directional antennas and you can get really great bitrates over long distances even with the relatively small EMF bandwidth that devices in that unlicensed range are allowed. WiMax does help you (potentially) by having a standard that hardware manufacturing companies can design to, getting you devices that work together.
Once you have your SNR you can do other things to try to get bitrates close to the theoretical limit, but turbo codes get us very close, and pretty much everyone uses them these days.
So there's really nothing new here as far as wireless communications. Good antennas and large frequency allocations get you nice datarates. What's new is that there is actually hardware supporting these high datarates and it is demonstratable.
WiBRO in Korea is: fixed antennas (good SNR) with large spectrum allocations (large B) and a good (but not magical) encoding scheme (OFDM). A pretty good solution for getting broadband to everyone without the investment of things like Fiber to the Curb or even copper wiring. Of course, this is the goal of WiBRO... Korea wants everyone in the country to have high datarate internet access from their homes.
I bought a PSP just so I could play Lumines, and now I'll have to buy an XBox 360 AND purchase it (again) online so I can play it on my big screen, play new skins, have more challenging computer opponents, and presumably other people online?
Cruel world! Why must you tempt me with your colored blocks and hypnotizing music?!!??!
(999,999-filled high score list. Everything unlocked. Got to about level 400 before I was too tired to keep concentration. Haven't yet done 100 blocks in 60 seconds. Playing versus the other guy in the office is really fun.)
I don't know about where you live, but where I live, the Salvation Army does a great deal of providing for the homeless, poor, and downtrodden. The Salvation Army is a denomiation of Christianity, like Presbyterian or Lutheran. Salvation Army locations hold church services, etc.
After seeing how the Government works (Katrina?), and experiencing how the Salvation Army works, I'd trust the Salvation Army with my money far more than I would trust the Government.
That low-level stuff is important if you have code that needs to run fast. Need to multiply a number by a constant? You can use shifts and adds instead. Does the same thing, but takes the processor less time.
INCORRECT
. Shifts and adds are sometimes faster for certain constants. Power of two, maybe power-of-two plus one. But for any arbitrary constant, this is false on most processors. Multipliers are much faster than a stream of many shifts and adds. Furthermore, the compiler should hold the knowledge of when a shift-and-add is better-performing than a multiply for what constant values. And, if you're not using MyPrettySchoolProjectCC, it probably does.
Now what your compiler *really* hopefully knows about is how to make division by a constant into a multiply. That can really save time. Division is an iterative process and is very hard to make fast. Multiplies are highly parallel; you can do large multiplies fully pipelined and with pretty low latency. And you can typically turn a 32 bit / 32 bit divide into a 32x32->64 multiply with the reciprocal. Since you can determine the reciprocal at compile time this is probably a win.
Maybe you just went to a school where they didn't show you how multiplies are actually implemented on modern hardware. Shift registers with accumulators they aren't. This is also potentially a reason why the professor will tell you that you can't outsmart the compiler. The typical college student can't, because he or she doesn't understand enough about how things really work. But any engineer with a decent amount of experience -- or most grad students -- can outsmart a compiler easily.
Quicksort is not the fastest sort in theory (surprised?)
I am. Show me a sorting algorithm that has better than O(N*log(N)) worst case behavior. You might be able to scrape off a few compares by adjusting the algorithm but the order of the algorithm doesn't get better than N log N. And that's really what matters.
There are sorting algorithms that work better in the real world, like Timsort.
The reason brilliant algorithm folks are necessary is that they can figure out how to turn algorithms from N^2 to N log N or N. Djikstra, for instance, figured out an N-order algorithm for determining if two circular lists are equivelant, much better than the N^2 method that probably comes to your mind first. And of course he is most famous for his graph traversal algorithm, which is used all over the internet for Open Shortest Path First routing.
And, of course, the reason that engineers are necessary is to keep the algorithm guys in the real world, to know what algorithms to pick, and to be able to invent systems that efficiently implement algorithms that solve problems.
When you pass a C file to a compiler, it generates an object file. It has absolutely no way of knowing where functions declared in the header are defined. You can hack around this; pass multiple source files to the compiler at once and have it treat them as a single one, for example, but this falls down completely when the function is declared in a library (e.g. libc) and you don't have access to the source.
If you want to do cross-file optimization, the (reasonably) elegant method is to leave the compiler IR in the.o file and then re-invoke the compiler at link time to do global optimization. This is what Open64 does. But it's not very reasonable to expect a compiler of any kind to optimize around libraries it doesn't have any notion of, is it? Can the java compiler optimize with some random library it has no notion of? Of course not.
(Now of course you can dynamically translate and optimize Java and optimize across library calls... but that's not a function of the language, but the interpreter's technology. You can do it with any type of application, including ones compiled with a C compiler. See projects like HP's Dynamo or Transmeta.)
By the way, I really reduced the number of visits to the local movie theaters, I went to watch the Superman though and it was terrible experience: it was a 10pm show and people brought their 2-3 year old kids
This is why I only watch movies at the Alamo Drafthouse Cinemas here in Austin. No children except at special showings (for Superman, no children under 6 and then only with parent). Even then, if they are noisy they will get thrown out. Also, no commercials and special movie-themed pre-show entertainment. (Unless you consider previews commercials, or 60's-era Car commercials before the movie Cars to be annoying commercials rather than fun pre-show entertainment... which I don't).
Also, they have good beer. Hooray, beer!
Seriously, if you like movies, the Alamo is a good reason to move to Austin. Or, at least, to visit.
OMAP (even OMAP3) is still an applications processor, it does not do baseband processing, you need a separate chip for UMTS/HSDPA/HSUPA. The DSP and coprocessors are for imaging, audio, and video. The ARM sucks as a DSP; you're not going to be able to do H.264 VGA encode/decode in software on an ARM.
Singular's card is HSDPA, the 3G packet access for folks upgrading GSM networks. If you're not in an area with HSDPA, you can fall back to EDGE or (probably) GPRS. You'll need a card that supports lots of bands if you expect to roam around the world... but GSM/GPRS/EDGE/HSDPA is what you'll find around Europe. So if the card supports all the frequencies you'd have compatible hardware there.
Verizon and Sprint use EV-DO cards. EV-DO is pretty widely deployed and growing fast. Make sure you get an EV-DO Revision A compatibile card. DOrA has even faster downlink and much faster uplink capabilities, as well as low-latency support so stuff like VoIP works better. EV-DO will fall back to normal 1x data... which is pretty fast. I get 100-200kbps just about everywhere on my cheapo 1x phone on Verizon. There are EV-DO networks in some Asian countries like Korea. And in my experience Verizon is the best wireless provider here in the USA.
I have a cheapo Verizon phone and find the normal 1xRTT to be pretty good for web browsing. SSH is a bit high latency but not bad. And it just costs airtime minutes. I wouldn't want to dist-upgrade debian with the link, but it's pretty good for what I need. Several folks in the office have the EV-DO cards and they work great in most cities.
If you are on a GSM network you also might find out that your phone does EDGE for free. Most phones -- even the cheap ones -- have data features. Find out and you might have a fun solution for an occasional need for wireless connectivity.
PS. Linux connectivity for the LG VX3200 was a snap... but I can't get it to work in Windows... does anyone have this working? I got a cheapo cable that comes up as a serial device...
The problem for most users is not the usability. Most users want to get email and web and word process. And maybe (with webmail) they don't even need an email client.
These people are people like my mom. My mom is fairly computer illiterate. She uses Debian Stable, kmail, firefox, and tetris. Occasionally she'll use one of the word processors available, but usually not. But she didn't have to install it and she doesn't
have to maintain it.
When she has a problem I can remotely log in and fix it. Her main problem so far: clock skew. This is after 2 years or so, on a $199 machine from Fry's.
Unlike when she had windows. Her computer got viruses and spyware. If she had a problem I really had no good way of helping her out. She's happier now with Linux.
She couldn't install Linux. But then again, she couldn't install windows, either. She couldn't administrate Linux or set up a printer. She couldn't do that under Windows either, probably.
I think we're getting to the point with Linux that the average person can use it and feel comfortable. However, administration and installation for both Windows and Linux is still difficult.
DDT use is allowed (even in the US, I think) for application around the home, ie. treating walls and such.
The alleged environmental impact was when the use was ultra-widespread, like dusting crops.
DDT is effective at fighting malaria in much of the world, applying just around the home, but chemical manufacturing companies
largely stopped making it after it got a bad name from the environmental concerns.
Copy-on-write for playing tricks with buffers during read() and write() type operations: (arguably) BAD
If you'd read TFA, you'd see that the issue is the API for doing zero-copy data movement (like sendfile()). You can give the buffer to the kernel, and then you shouldn't mess with the buffer until the kernel is done (this is Linus's preference). OR, you can re-mark the page with the buffer in it as read-only, and then if the user DOES modify something in the page with the buffer before the kernel is finished with it, the kernel can copy the page, mark it writable, and restart the process. Once the kernel is finished with the page, the page may be freed.
TLB shootdowns and refills are expensive. So if you do Linus's preference, you avoid that penalty. The cost is that you have to remember to ask the kernel to notify you when it is finished. Or you can do the BSD thing, which looks nicer from a programming standpoint, but the cost of the implementation is higher.
The COW situation is exacerbated with multiple page sizes... if you are trying to get better utilization from your TLB by using large (ie, 4M) pages, modifying something in the page may be very likely, especially in a multithreaded application where most of the page may hold information completely unrelated to the buffer.
Slashdot Mirror
The same reason ARM code is faster than THUMB. When you compile an algorithm to a bytecode, it probably takes more instructions than it would take using 32-bit ARM instructions. When you JIT you don't just convert a bytecode to an ARM instruction, you do some optimization, and the resulting code is typically faster.
There are also other optimizations you can do at execution time that you just can't do at compile time. This is why work you do in the microarchitecture pays off (ie, out of order execution, alias detection, etc), but you can also find interesting things like HP Dynamo that find speedups in JIT recompiling PA-RISC to PA-RISC. Fun read, check it out. Ars technica article here, real paper here
On most ARM implementations, it's a state machine that dispatches multiple load operations... and because you can write the program counter like a normal register you can get branch functionality at the same time. It's crazy. Anyway, in my opinion, if you have to have a state machine to turn one instruction magically into many instructions it doesn't meet the "RISC philosophy" of having simple instructions that just shoot down the pipeline.
But RISC is just a word, and different people believe different things. I know folks who think that RISC means "an instrucion set with few instructions." In reality, things are just shades of grey, with (I guess) MIPS being on one end and oh, maybe x86 or VAX on the other.
Better on FP, somewhat, but only ~1/2 the score on INT.
Please tell me what processor does better than Core 2 Duo on SPEC CPU?
ARM processors have microcoded instructions (ldm/stm) ... which certainly doesn't jive with most folk's definition of RISC.
Jazelle isn't a JIT, it executes bytecodes directly and traps for ones it doesn't understand.
Also, any halfway-decent java JIT can outperform an ARM in Jazelle mode.
Intel chips haven't really executed x86 since the original Pentium. They translate the instructions into a more convienient form and execute those. They do analysis in hardware and find all sorts of opportunities to make code run faster.
As it turns out, you have to do most of the same analysis to get good performance on a RISC too. So you have a bit of extra decoding work, which you might not have to do on a MIPS or something, but you gain some flexibility in what lies underneath. And if you're producing 10x the amount of processors as Freescale, you're going to be able to make up for any marginal increase in cost the extra complexity costs you.
Also, don't buy into the hype. You can't buy that much from a good ISA on high-end processors. Look at the SPEC numbers for the Core 2 duo vs. anyone else if you don't believe me. IA64 was supposed to be the greatest thing ever because compilers could do all the work at compile time. There's almost every instruction set hook imaginable in IA64. And look how that architecture has turned out.
We use x86 because instruction translation is pretty easy and very effective... the same reason why Java algorithms perform pretty well, Transmeta had a halfway decent chip, Alpha could execute x86 code pretty well, and Apple can run PPC apps pretty well on x86. It's not bad enough to be completely broken, and we can engineer our way out of the problems in the architecture.
Of course, if you're counting transistors and joules, some of this breaks down... that's why ARM and DSPs have been effective at the low end.
Example college at GT: School of Electrical and Computer Engineering
Example college at UGA: School of Poultry Science(sic)
You can't get an Engineering degree from UGA. Similarly, you can't get a Literature degree from Georgia Tech.
Time to continue ramblin'.
Anyway, if our government can't be fiscally responsible (or even fiscally ethical) in its programs, how can it expect to have moral authority over real life financial scams, much less ones in video games?
If the SNR is very high and so is the bandwitdth, you can transmit a lot of data. We could already do that with things like optical and electrical cables, microwave links, etc.
Some features of a wireless link can help you improve SNR. For instance, you can use things like rake receivers to reduce multipath interference. But you're never going to do all that well in a building, in a city, with tons of EMF interference from all sorts of things, with a single, tiny, omnidirectional antenna. Especially if you want your mobile device to work when you start moving around at 200kph.
So if you have a big, fixed, maybe directional antenna with line-of-site to the basestation, and you've allocated a large chunk of spectrum, it's easy to get a high datarate. WiMax doesn't help you all that much, some of the OFDM tricks it uses help out some but is fundamentally it's not all that much better than anything we already have. For example, you hook up 802.11g through high-SNR directional antennas and you can get really great bitrates over long distances even with the relatively small EMF bandwidth that devices in that unlicensed range are allowed. WiMax does help you (potentially) by having a standard that hardware manufacturing companies can design to, getting you devices that work together.
Once you have your SNR you can do other things to try to get bitrates close to the theoretical limit, but turbo codes get us very close, and pretty much everyone uses them these days.
So there's really nothing new here as far as wireless communications. Good antennas and large frequency allocations get you nice datarates. What's new is that there is actually hardware supporting these high datarates and it is demonstratable.
WiBRO in Korea is: fixed antennas (good SNR) with large spectrum allocations (large B) and a good (but not magical) encoding scheme (OFDM). A pretty good solution for getting broadband to everyone without the investment of things like Fiber to the Curb or even copper wiring. Of course, this is the goal of WiBRO... Korea wants everyone in the country to have high datarate internet access from their homes.
Cruel world! Why must you tempt me with your colored blocks and hypnotizing music?!!??!
(999,999-filled high score list. Everything unlocked. Got to about level 400 before I was too tired to keep concentration. Haven't yet done 100 blocks in 60 seconds. Playing versus the other guy in the office is really fun.)
After seeing how the Government works (Katrina?), and experiencing how the Salvation Army works, I'd trust the Salvation Army with my money far more than I would trust the Government.
yodav("That is why you fail.");
I like C, and I tend to write imperative Python. But for what I do, that's very appropriate.
But if you are referring to a dialect of Lisp as a language that "sucks", you need more in your brain before you open your mouth.
INCORRECT
. Shifts and adds are sometimes faster for certain constants. Power of two, maybe power-of-two plus one. But for any arbitrary constant, this is false on most processors. Multipliers are much faster than a stream of many shifts and adds. Furthermore, the compiler should hold the knowledge of when a shift-and-add is better-performing than a multiply for what constant values. And, if you're not using MyPrettySchoolProjectCC, it probably does.Now what your compiler *really* hopefully knows about is how to make division by a constant into a multiply. That can really save time. Division is an iterative process and is very hard to make fast. Multiplies are highly parallel; you can do large multiplies fully pipelined and with pretty low latency. And you can typically turn a 32 bit / 32 bit divide into a 32x32->64 multiply with the reciprocal. Since you can determine the reciprocal at compile time this is probably a win.
Maybe you just went to a school where they didn't show you how multiplies are actually implemented on modern hardware. Shift registers with accumulators they aren't. This is also potentially a reason why the professor will tell you that you can't outsmart the compiler. The typical college student can't, because he or she doesn't understand enough about how things really work. But any engineer with a decent amount of experience -- or most grad students -- can outsmart a compiler easily.
I am. Show me a sorting algorithm that has better than O(N*log(N)) worst case behavior. You might be able to scrape off a few compares by adjusting the algorithm but the order of the algorithm doesn't get better than N log N. And that's really what matters.
There are sorting algorithms that work better in the real world, like Timsort.
The reason brilliant algorithm folks are necessary is that they can figure out how to turn algorithms from N^2 to N log N or N. Djikstra, for instance, figured out an N-order algorithm for determining if two circular lists are equivelant, much better than the N^2 method that probably comes to your mind first. And of course he is most famous for his graph traversal algorithm, which is used all over the internet for Open Shortest Path First routing.
And, of course, the reason that engineers are necessary is to keep the algorithm guys in the real world, to know what algorithms to pick, and to be able to invent systems that efficiently implement algorithms that solve problems.
You can write a C compiler for the SPEs on Cell.
If you want to do cross-file optimization, the (reasonably) elegant method is to leave the compiler IR in the
(Now of course you can dynamically translate and optimize Java and optimize across library calls... but that's not a function of the language, but the interpreter's technology. You can do it with any type of application, including ones compiled with a C compiler. See projects like HP's Dynamo or Transmeta.)
This is why I only watch movies at the Alamo Drafthouse Cinemas here in Austin. No children except at special showings (for Superman, no children under 6 and then only with parent). Even then, if they are noisy they will get thrown out. Also, no commercials and special movie-themed pre-show entertainment. (Unless you consider previews commercials, or 60's-era Car commercials before the movie Cars to be annoying commercials rather than fun pre-show entertainment... which I don't).
Also, they have good beer. Hooray, beer!
Seriously, if you like movies, the Alamo is a good reason to move to Austin. Or, at least, to visit.
OMAP (even OMAP3) is still an applications processor, it does not do baseband processing, you need a separate chip for UMTS/HSDPA/HSUPA. The DSP and coprocessors are for imaging, audio, and video. The ARM sucks as a DSP; you're not going to be able to do H.264 VGA encode/decode in software on an ARM.
Verizon and Sprint use EV-DO cards. EV-DO is pretty widely deployed and growing fast. Make sure you get an EV-DO Revision A compatibile card. DOrA has even faster downlink and much faster uplink capabilities, as well as low-latency support so stuff like VoIP works better. EV-DO will fall back to normal 1x data... which is pretty fast. I get 100-200kbps just about everywhere on my cheapo 1x phone on Verizon. There are EV-DO networks in some Asian countries like Korea. And in my experience Verizon is the best wireless provider here in the USA.
I have a cheapo Verizon phone and find the normal 1xRTT to be pretty good for web browsing. SSH is a bit high latency but not bad. And it just costs airtime minutes. I wouldn't want to dist-upgrade debian with the link, but it's pretty good for what I need. Several folks in the office have the EV-DO cards and they work great in most cities.
If you are on a GSM network you also might find out that your phone does EDGE for free. Most phones -- even the cheap ones -- have data features. Find out and you might have a fun solution for an occasional need for wireless connectivity.
PS. Linux connectivity for the LG VX3200 was a snap... but I can't get it to work in Windows... does anyone have this working? I got a cheapo cable that comes up as a serial device...
These people are people like my mom. My mom is fairly computer illiterate. She uses Debian Stable, kmail, firefox, and tetris. Occasionally she'll use one of the word processors available, but usually not. But she didn't have to install it and she doesn't have to maintain it.
When she has a problem I can remotely log in and fix it. Her main problem so far: clock skew. This is after 2 years or so, on a $199 machine from Fry's.
Unlike when she had windows. Her computer got viruses and spyware. If she had a problem I really had no good way of helping her out. She's happier now with Linux.
She couldn't install Linux. But then again, she couldn't install windows, either. She couldn't administrate Linux or set up a printer. She couldn't do that under Windows either, probably.
I think we're getting to the point with Linux that the average person can use it and feel comfortable. However, administration and installation for both Windows and Linux is still difficult.
The alleged environmental impact was when the use was ultra-widespread, like dusting crops.
DDT is effective at fighting malaria in much of the world, applying just around the home, but chemical manufacturing companies largely stopped making it after it got a bad name from the environmental concerns.
Copy-on-write for fork(): GOOD
Copy-on-write for playing tricks with buffers during read() and write() type operations: (arguably) BAD
If you'd read TFA, you'd see that the issue is the API for doing zero-copy data movement (like sendfile()). You can give the buffer to the kernel, and then you shouldn't mess with the buffer until the kernel is done (this is Linus's preference). OR, you can re-mark the page with the buffer in it as read-only, and then if the user DOES modify something in the page with the buffer before the kernel is finished with it, the kernel can copy the page, mark it writable, and restart the process. Once the kernel is finished with the page, the page may be freed.
TLB shootdowns and refills are expensive. So if you do Linus's preference, you avoid that penalty. The cost is that you have to remember to ask the kernel to notify you when it is finished. Or you can do the BSD thing, which looks nicer from a programming standpoint, but the cost of the implementation is higher.
The COW situation is exacerbated with multiple page sizes... if you are trying to get better utilization from your TLB by using large (ie, 4M) pages, modifying something in the page may be very likely, especially in a multithreaded application where most of the page may hold information completely unrelated to the buffer.
Not that I'm an addict. I could stop any time I want.