A page containing the words "Dual Core XScale", does not a dual-core Xscale make. The only pages I can find that have that text are either marketing materials or they refer to dual CPU designs. I cannot find links to actual dual-core Xscale designs.
I work with the latest Xscale stuff, and I've never heard of a dual-core Xscale. Either Marvell have done major work in the last few months to make a PXA chip dual core, or there is some sort of marketing goof here. ARM does design some multi-core chips for their very cutting edge stuff, but PXA chips are not doing that.
I'd love to get some links to this "dual-core Xscale" if I am wrong though!
for the last 5 years or so. Unless CE offers you some turn key solutions that are really appealing and not found on Linux, then embedded Linux is for sure the way to go. Simply speaking, you will get no support from Microsoft without dumping bucket loads of cash & if it isn't the latest release of the OS then you have no hope at all. The MS newsgroups are many times poorer for support than Linux mailing lists. At least with Linux you can hire someone to work on old code, because you have the code!
MS only cares about the big players (iPaq, Dell) and now they are moving into the phone market as well. Don't expect to get more than the time it takes them to sell you a license. Developing with WinCE is an extremely daunting task if you haven't done it before. So is Linux, the difference is 1) Amount of online support from newsgroups, etc 2) Actually being able to see the code that runs Linux. 9 times out of 10 it doesn't matter, but that 1 time out of ten really makes you want to put pins in your eyes.
Do I sound bitter that my current job is exclusively WinCE?????
The rugged PDA in the photo is a Recon device from Tripod Data (www.tdsway.com). I work there, and occasionally work on that product. Anyhow the picture in the article of the device is actually running PocketPC2003, not Linux. I guess that they are just using the Recon as a user interface & have a more powerful Linux computer stashed somewhere else. Linux has been ported to the Recon though.
This late in the day, the hardware for manufacture will be final. However, the final hardware may not have been what Apple actually showed, but perhaps the final hardware was due back a couple of days after Mac World. The protos that we saw may be a couple of months old.
Also, I imagine that the software guys will need to put a bit of work into the powersaving features of the CPU, turning off a core, speedstep, etc. I also wouldn't be surprised to see OSX releases soon after MacBook ship that improve the battery life.
I agree. I've seen Dasher running really quite nicely on a 200 & 400 Mhz PXA255 Linux system. I believe that the TI chip should be somewhat comparable. Also, if it is the FP in Dasher causing a problem, you can link to software FP libraries, which ought to be lots faster than the kernel method (the CPU executes an FP instruction, which causes an unknown instruction abort. The kernel traps the abort and synthesises the FP in software. Yes, it is as slow as it sounds:)
Since he is the IT manager, presumably for tech decisions the buck stops at him. I bet he isn't suggesting that the peon-level help deskers just install new software, he is saying that when you have the authority to make the choice go for it. Realistically he has superiors, but they don't know about IT. This kind of "make the change without telling anyone" is probably within his job scope - and if the system appears not to change for the users the everyone is happy.
It doesn't. The ARM chip is in a different market, they're talking 0.3W and the PPC chip is talking 5-25W, an order of magnitude difference. Some of the guys involved in this startup worked on the Alpha & StrongARM chips - both chips were ahead of their time & very good CPUs. I think they'll make nice PPC chips in a couple of years time.
Isn't this a classic example of
1) There not being a problem in the first place
2) Management trying to solve the problem, when it is a technical matter.
Firstly - who really cares? This kind of optimisation almost never occurs as far as I can tell. Secondly, counting CPU instructions hasn't been accurate for years. Thirdly, for any kind of memory access loop, cache misses will most likely be your biggest performance hit. The best way to actually improve this loop is probably going to be by... 1) if the length of the data is 4k, just do the algorithm 2) otherwise, stride through the data in page-size increments reading 1 32bit word, then do the algorithm
But seriously - either you are working in a system so small and slow that you are already an expert in this stuff, or this kind of optimisation doesn't matter. Choose quicksort instead of bubble sort.
Come on - this has to be a troll! Perfect title, good weighting in the blurb, nice "put it in Windows terms" and then the very reasonable "oh. but I fully support Linux"
I'll bet dollars to dimes that they didn't have a good Unix Sysadmin on board, just some guy who was trying Linux out. And I bet we see more of these "failures" when people try Linux expecting it to be a silver bullet & cry when they get burned because they don't have the qualified staff.
I have seen a lot of people saying that the main performance enhancement in going to x86-64 for most apps is that you have more registers. While I am the first to agree that the x86 instruction set is register starved, I was under the impression that most modern CPUs implemented register masking (I can't remember the exact term, it could also be banking or caching). I basically thought that the hardware did fancy things to "cache" registers, so that even though it looks like you're having to fetch stuff from the stack - you are infact getting it from a very fast on-die location.
Really? I can't find anywhere that people have writen emulators that run the Xbox on non x86 hardware. I found some stuff that suggests people have emulators working on x86 hardware though. This isn't the same thing though.
I think that emulating hardware in software is extremely difficult (if it matters at all, I've done it for a simple FPGA design & it is not fun)
- The graphics card is different, fine if you only used DX9 in your xbox game, sucky if you talked right to the metal. And I bet that most good games put a lot of work into getting the best out of that specific chunk of hardware
- multiple cores don't matter one little bit when you are emulating a single core machine, so you need to emulate a 733Mhz Celeron on a 3.2 Ghz PPC
I really don't think that this will be child's play, otherwise MS would be shouting backwards compatibility from the roof tops. Instead all we hear is how "some games will work"
Simple, because people using Apple's Rossetta will be running applications where the absolute speed of the program doesn't matter all that much.
Xbox360 doing Xbox emulation needs to be correct, fast and smooth. The correct part is only slightly hard. The fast and smooth parts are extremely hard.
I don't buy this for one second. The article basically boils down to "Apple is switching their whole line to Intel to get better deals on Xscale CPUs". The iPods currently run a cute little dual code ARM7, which I am guessing costs them about $3-5 dollars (maybe less) in the volume they get them. To move to the latest XScale from Intel, even with REALLY good discount I think they'd have to be paying on the order of $20-25 per chip. Low volume vendors pay around $40. Also, the Xscale is not the most power friendly ARM cpu in the world - far more expensive than the current ARM7 the iPods use.
So unless you really need the power of an Xscale (and an Xscale won't be able to decode video at a resolution high enough to pipe to a TV), then you don't use it.
With volume manufacture, every cent of cost comes directly off the bottom line and you use the absolute minimal parts that will get the job done.
While Apple may put out an Xscale device, I really doubt they switched their entire line to get a few dollars discount on the CPU purchase.
As I read it, PJ and New Line signed an agreement which said PJ would get a percentage of gross profit. If I were signing such a contract then I would expect a good faith attempt to maximise profit, because that is beneficial to all. However, what New Line appears to have done is to deliberately NOT make the maximum profit, they have shuffled money sideways into a sister corporation. In this way they can say "we only made x dollars", where in reality the New Line corp as a whole did far better than that. For example, imagine that you went to work for some guy & agreed to get paid 20% of what the business grossed, after a year you discover that the business isn't doing so well because the major shareholder takes a huge cut of the profit - and guess what, the major share holder turns out to be married to the boss. Yes, you're getting ripped off. I say good luck to PJ, I'm pretty sure that he has been ripped off.
How much accuracy do you need? Block level? City level? State, country or continent level? GPS may not give you sub-metre accuracy in hostile environments, but it is going to be more than good enough to enforce coarse level protection. Remember that all cell phones are going to need GPS capiblities for 911 purposes soon.
So, it's not BS. For the purposes of region encoding you could very easily make a cheap and effective GPS sensing device that did the job.
The New Zealand government basically does this already, but in an even simpler form - you don't even need to check!! Most people who simply earn a wage have a simple enough tax return that the government simply deducts tax from your pay cheque - and that is all you need to do. If you want to fill a tax form out (because of complex investments, etc) then you can - but probably something like 70-80% of people don't bother.
Of course, the NZ tax scheme is actually sane and easy to work out compared to some US taxes.
I thought that developers would still be at WWDC, and that it would take a couple of weeks for them to get their machines. And the other thing is, surely Apple didn't just give them a nice install DVD - they would have just preinstalled the system.
Now, if it has leaked already, and Apple did give them a nice, easily installable DVD - then yes I think that Apple has done this deliberately. If Apple doesn't bother to go after the leaker, or can't find them - then this is an Apple "release".
I really have a thing for these people who would rather live in the dark ages. Sure, they're happy that modern technology gives them food on the table, power in their houses, and enough free time to go and protest. But, WHOA there fella, we don't want any of that new potentially harmful technology stuff around here. The potential benefits of a working nanotechnology far outweigh any potential problems - but noooo, we don't want humanity living in a clean environment where manufacture of goods is cheap and automatic - what would we protest about then?
Damn I hate it when people are stupid, don't even get me started about how some people think it is better to BURN COAL than use nuclear power plants.
Bah, they weren't even hot naked protesters either!
One of the best places I worked was a place where the boss understood that happy workers are productive workers. And workers that are required to work longers hours simply don't get more work done. This guy kept us happy with relatively cheap methods - decent coffee, free biscuits/cookies and taking us out to lunch/dinner on a regular basis. Even under stress times he told us to leave for the day. Interestingly this made people want to stay later and work harder.
At other places I have worked there has been an expectation of "we're near deadline, work an extra few hours every night" - for me this doesn't work. I get less done in more time, I end up sitting watching the clock or reading Slashdot, and resenting staying at work.
The solution to getting things done on time is simple 1) Hire smart people who get along with each other 2) Don't push them, let them work hard for 8 hours and then go home 3) Don't choose arbitary dates for shipping 4) Don't let features creap into the spec.
This won't decrease the gap between porting games. Though I am not a professional game developer, I find it hard to imagine that modern games have much (if any) assembler content in them. Any language higher level than assembly was already able to be compiled for other CPUs - so the actual machine instructions have never been a problem.
Endianness is a small issue, really there are only a few places that you need to fix up for that, so that has never been a real problem. The APIs that you use to make your game are the big problems, DirectX for example.
There are a couple of things that do make this better for Mac gamers. Raw computing power for the Mac user base will generally rise, after all how many people are trying (and failing) to run games on underpowered iBooks? Now if Apple supports and promotes OpenGL2.0 and perhaps OpenAL, then maybe game developers will target those APIs. In which case porting between Windows and OS X should be easier.
The truely interesting thing is that we are going to see how much OS overhead there is between Windows and OS X - a more Apples to Apples comparison:) If OS X is significantly more efficient than WinXP, then people will really start to target Macs as development platforms.
Changing from PPC to x86 architecture is a big deal - but the hardest part of it will, IMHO, be converting the Altivec optimised code. And I can't really think of a way around it. But here are some options that might work:
1) Altivec emulation at run time on the x86 CPU - presumably the Intel chips will have SSE3.
2) Intel puts Altivec (or makes SSE3 sufficiently like it) into the chips it will make for Apple.
3) The best solution IMHO is; Apple starts emphasising vector processing in a a way that is not Altivec specific - you can already see this with their vector additions to GCC & CoreImage, etc. In a year's time the x86 Macs will be equiped with good GPUs, GPUs able to do Altivec like operations, so Apple utilises GPUs as general purpose SIMD processors.
I figure that either 1) Intel will get in on the PPC game and sell PPC to Apple (which makes sense, because they may also be able to sell PPC to the next gen console makers) 2) Apple is wanting to buy Intel's Xscale processor. The Xscale isn't the best ARM processor out there, but it has a decent clock speed (620Mhz). If Apple is going after the Xscale CPU, then also expect a new product somewhere between an iPod and an iBook. Because the CPU is too power hungry for any iPod like devices (iPods use little dual core ARM7's), the new product will have to be "bigger" than an iPod. Maybe an iPod video that outputs to a TV? I don't think that it makes sense to run something as big as a tablet from the Xscale, something that side may as well use PPC and then run all the stock OSX apps.
Re:Arm port of Debian
on
Juicebox Hacking
·
· Score: 3, Interesting
I don't think it will be quite that easy. The CPU in this thing is an ARM7 with no MMU - which is why it runs uclinux instead of regular linux. That means that you can't just drop regular packages onto it. I think that you need to custom locate (in memory) each package that you want to run, and compile it yourself.
I could be wrong - but it certainly isn't going to be as easy as just running Debian on it.
Slashdot Mirror
A page containing the words "Dual Core XScale", does not a dual-core Xscale make.
The only pages I can find that have that text are either marketing materials or they refer to dual CPU designs. I cannot find links to actual dual-core Xscale designs.
I work with the latest Xscale stuff, and I've never heard of a dual-core Xscale. Either Marvell have done major work in the last few months to make a PXA chip dual core, or there is some sort of marketing goof here.
ARM does design some multi-core chips for their very cutting edge stuff, but PXA chips are not doing that.
I'd love to get some links to this "dual-core Xscale" if I am wrong though!
Cheers
for the last 5 years or so. Unless CE offers you some turn key solutions that are really appealing and not found on Linux, then embedded Linux is for sure the way to go.
Simply speaking, you will get no support from Microsoft without dumping bucket loads of cash & if it isn't the latest release of the OS then you have no hope at all. The MS newsgroups are many times poorer for support than Linux mailing lists.
At least with Linux you can hire someone to work on old code, because you have the code!
MS only cares about the big players (iPaq, Dell) and now they are moving into the phone market as well. Don't expect to get more than the time it takes them to sell you a license. Developing with WinCE is an extremely daunting task if you haven't done it before. So is Linux, the difference is
1) Amount of online support from newsgroups, etc
2) Actually being able to see the code that runs Linux. 9 times out of 10 it doesn't matter, but that 1 time out of ten really makes you want to put pins in your eyes.
Do I sound bitter that my current job is exclusively WinCE?????
The rugged PDA in the photo is a Recon device from Tripod Data (www.tdsway.com). I work there, and occasionally work on that product. Anyhow the picture in the article of the device is actually running PocketPC2003, not Linux. I guess that they are just using the Recon as a user interface & have a more powerful Linux computer stashed somewhere else. Linux has been ported to the Recon though.
This late in the day, the hardware for manufacture will be final. However, the final hardware may not have been what Apple actually showed, but perhaps the final hardware was due back a couple of days after Mac World. The protos that we saw may be a couple of months old.
Also, I imagine that the software guys will need to put a bit of work into the powersaving features of the CPU, turning off a core, speedstep, etc. I also wouldn't be surprised to see OSX releases soon after MacBook ship that improve the battery life.
I agree. I've seen Dasher running really quite nicely on a 200 & 400 Mhz PXA255 Linux system. I believe that the TI chip should be somewhat comparable. :)
Also, if it is the FP in Dasher causing a problem, you can link to software FP libraries, which ought to be lots faster than the kernel method (the CPU executes an FP instruction, which causes an unknown instruction abort. The kernel traps the abort and synthesises the FP in software. Yes, it is as slow as it sounds
Since he is the IT manager, presumably for tech decisions the buck stops at him. I bet he isn't suggesting that the peon-level help deskers just install new software, he is saying that when you have the authority to make the choice go for it. Realistically he has superiors, but they don't know about IT. This kind of "make the change without telling anyone" is probably within his job scope - and if the system appears not to change for the users the everyone is happy.
It doesn't. The ARM chip is in a different market, they're talking 0.3W and the PPC chip is talking 5-25W, an order of magnitude difference.
Some of the guys involved in this startup worked on the Alpha & StrongARM chips - both chips were ahead of their time & very good CPUs.
I think they'll make nice PPC chips in a couple of years time.
Isn't this a classic example of 1) There not being a problem in the first place 2) Management trying to solve the problem, when it is a technical matter.
Firstly - who really cares? This kind of optimisation almost never occurs as far as I can tell. Secondly, counting CPU instructions hasn't been accurate for years. Thirdly, for any kind of memory access loop, cache misses will most likely be your biggest performance hit. The best way to actually improve this loop is probably going to be by...
1) if the length of the data is 4k, just do the algorithm
2) otherwise, stride through the data in page-size increments reading 1 32bit word, then do the algorithm
But seriously - either you are working in a system so small and slow that you are already an expert in this stuff, or this kind of optimisation doesn't matter.
Choose quicksort instead of bubble sort.
Come on - this has to be a troll! Perfect title, good weighting in the blurb, nice "put it in Windows terms" and then the very reasonable "oh. but I fully support Linux"
I'll bet dollars to dimes that they didn't have a good Unix Sysadmin on board, just some guy who was trying Linux out. And I bet we see more of these "failures" when people try Linux expecting it to be a silver bullet & cry when they get burned because they don't have the qualified staff.
I have seen a lot of people saying that the main performance enhancement in going to x86-64 for most apps is that you have more registers.
While I am the first to agree that the x86 instruction set is register starved, I was under the impression that most modern CPUs implemented register masking (I can't remember the exact term, it could also be banking or caching). I basically thought that the hardware did fancy things to "cache" registers, so that even though it looks like you're having to fetch stuff from the stack - you are infact getting it from a very fast on-die location.
Can anyone familiar with modern x86 guts comment?
Really? I can't find anywhere that people have writen emulators that run the Xbox on non x86 hardware. I found some stuff that suggests people have emulators working on x86 hardware though. This isn't the same thing though. I think that emulating hardware in software is extremely difficult (if it matters at all, I've done it for a simple FPGA design & it is not fun) - The graphics card is different, fine if you only used DX9 in your xbox game, sucky if you talked right to the metal. And I bet that most good games put a lot of work into getting the best out of that specific chunk of hardware - multiple cores don't matter one little bit when you are emulating a single core machine, so you need to emulate a 733Mhz Celeron on a 3.2 Ghz PPC I really don't think that this will be child's play, otherwise MS would be shouting backwards compatibility from the roof tops. Instead all we hear is how "some games will work"
Simple, because people using Apple's Rossetta will be running applications where the absolute speed of the program doesn't matter all that much. Xbox360 doing Xbox emulation needs to be correct, fast and smooth. The correct part is only slightly hard. The fast and smooth parts are extremely hard.
I don't buy this for one second. The article basically boils down to "Apple is switching their whole line to Intel to get better deals on Xscale CPUs". The iPods currently run a cute little dual code ARM7, which I am guessing costs them about $3-5 dollars (maybe less) in the volume they get them. To move to the latest XScale from Intel, even with REALLY good discount I think they'd have to be paying on the order of $20-25 per chip. Low volume vendors pay around $40.
Also, the Xscale is not the most power friendly ARM cpu in the world - far more expensive than the current ARM7 the iPods use.
So unless you really need the power of an Xscale (and an Xscale won't be able to decode video at a resolution high enough to pipe to a TV), then you don't use it.
With volume manufacture, every cent of cost comes directly off the bottom line and you use the absolute minimal parts that will get the job done.
While Apple may put out an Xscale device, I really doubt they switched their entire line to get a few dollars discount on the CPU purchase.
As I read it, PJ and New Line signed an agreement which said PJ would get a percentage of gross profit. If I were signing such a contract then I would expect a good faith attempt to maximise profit, because that is beneficial to all.
However, what New Line appears to have done is to deliberately NOT make the maximum profit, they have shuffled money sideways into a sister corporation. In this way they can say "we only made x dollars", where in reality the New Line corp as a whole did far better than that.
For example, imagine that you went to work for some guy & agreed to get paid 20% of what the business grossed, after a year you discover that the business isn't doing so well because the major shareholder takes a huge cut of the profit - and guess what, the major share holder turns out to be married to the boss. Yes, you're getting ripped off.
I say good luck to PJ, I'm pretty sure that he has been ripped off.
How much accuracy do you need? Block level? City level? State, country or continent level? GPS may not give you sub-metre accuracy in hostile environments, but it is going to be more than good enough to enforce coarse level protection. Remember that all cell phones are going to need GPS capiblities for 911 purposes soon.
So, it's not BS. For the purposes of region encoding you could very easily make a cheap and effective GPS sensing device that did the job.
The New Zealand government basically does this already, but in an even simpler form - you don't even need to check!!
Most people who simply earn a wage have a simple enough tax return that the government simply deducts tax from your pay cheque - and that is all you need to do.
If you want to fill a tax form out (because of complex investments, etc) then you can - but probably something like 70-80% of people don't bother.
Of course, the NZ tax scheme is actually sane and easy to work out compared to some US taxes.
I thought that developers would still be at WWDC, and that it would take a couple of weeks for them to get their machines.
And the other thing is, surely Apple didn't just give them a nice install DVD - they would have just preinstalled the system.
Now, if it has leaked already, and Apple did give them a nice, easily installable DVD - then yes I think that Apple has done this deliberately. If Apple doesn't bother to go after the leaker, or can't find them - then this is an Apple "release".
I really have a thing for these people who would rather live in the dark ages. Sure, they're happy that modern technology gives them food on the table, power in their houses, and enough free time to go and protest. But, WHOA there fella, we don't want any of that new potentially harmful technology stuff around here. The potential benefits of a working nanotechnology far outweigh any potential problems - but noooo, we don't want humanity living in a clean environment where manufacture of goods is cheap and automatic - what would we protest about then?
Damn I hate it when people are stupid, don't even get me started about how some people think it is better to BURN COAL than use nuclear power plants.
Bah, they weren't even hot naked protesters either!
One of the best places I worked was a place where the boss understood that happy workers are productive workers. And workers that are required to work longers hours simply don't get more work done.
This guy kept us happy with relatively cheap methods - decent coffee, free biscuits/cookies and taking us out to lunch/dinner on a regular basis.
Even under stress times he told us to leave for the day. Interestingly this made people want to stay later and work harder.
At other places I have worked there has been an expectation of "we're near deadline, work an extra few hours every night" - for me this doesn't work. I get less done in more time, I end up sitting watching the clock or reading Slashdot, and resenting staying at work.
The solution to getting things done on time is simple
1) Hire smart people who get along with each other
2) Don't push them, let them work hard for 8 hours and then go home
3) Don't choose arbitary dates for shipping
4) Don't let features creap into the spec.
But managers don't seem to understand this.
This won't decrease the gap between porting games. Though I am not a professional game developer, I find it hard to imagine that modern games have much (if any) assembler content in them. Any language higher level than assembly was already able to be compiled for other CPUs - so the actual machine instructions have never been a problem.
:) If OS X is significantly more efficient than WinXP, then people will really start to target Macs as development platforms.
Endianness is a small issue, really there are only a few places that you need to fix up for that, so that has never been a real problem.
The APIs that you use to make your game are the big problems, DirectX for example.
There are a couple of things that do make this better for Mac gamers. Raw computing power for the Mac user base will generally rise, after all how many people are trying (and failing) to run games on underpowered iBooks?
Now if Apple supports and promotes OpenGL2.0 and perhaps OpenAL, then maybe game developers will target those APIs. In which case porting between Windows and OS X should be easier.
The truely interesting thing is that we are going to see how much OS overhead there is between Windows and OS X - a more Apples to Apples comparison
Changing from PPC to x86 architecture is a big deal - but the hardest part of it will, IMHO, be converting the Altivec optimised code. And I can't really think of a way around it. But here are some options that might work:
1) Altivec emulation at run time on the x86 CPU - presumably the Intel chips will have SSE3.
2) Intel puts Altivec (or makes SSE3 sufficiently like it) into the chips it will make for Apple.
3) The best solution IMHO is; Apple starts emphasising vector processing in a a way that is not Altivec specific - you can already see this with their vector additions to GCC & CoreImage, etc. In a year's time the x86 Macs will be equiped with good GPUs, GPUs able to do Altivec like operations, so Apple utilises GPUs as general purpose SIMD processors.
I figure that either
1) Intel will get in on the PPC game and sell PPC to Apple (which makes sense, because they may also be able to sell PPC to the next gen console makers)
2) Apple is wanting to buy Intel's Xscale processor. The Xscale isn't the best ARM processor out there, but it has a decent clock speed (620Mhz). If Apple is going after the Xscale CPU, then also expect a new product somewhere between an iPod and an iBook. Because the CPU is too power hungry for any iPod like devices (iPods use little dual core ARM7's), the new product will have to be "bigger" than an iPod. Maybe an iPod video that outputs to a TV? I don't think that it makes sense to run something as big as a tablet from the Xscale, something that side may as well use PPC and then run all the stock OSX apps.
I don't think it will be quite that easy. The CPU in this thing is an ARM7 with no MMU - which is why it runs uclinux instead of regular linux. That means that you can't just drop regular packages onto it. I think that you need to custom locate (in memory) each package that you want to run, and compile it yourself. I could be wrong - but it certainly isn't going to be as easy as just running Debian on it.