The N900 has actually 256MB of RAM (plus 768 of virtual memory using the flash storage). Previous Nokia models, as the N800 (without telephone, just a tablet PC) had just 128MB of RAM and 256MB of flash. That amount of ram costs below 10 USD. I see no problem for sub 70-150 USD full-fledged Maemo/Linux phones.
As it is NP = P. The main handicap for NP = P is to sort the space solution dynamically, without expanding all permutations, avoiding combinatorial explosion. Other problem is that it is not trivial to fragment or address the space within a unexpanded solution for the permutation-space.
Translation: "Government, companies, and families owe 2.7 trillion, which is about 250% of the Spanish GDP"
Those "2,7 billones" are 2.7*10^12, as in Spain we use the long scale, equals to 2.7 US/UK trillion (short-scale). In USD would be about 4 trillion (not much different from the 3.75 I posted in the previous post), so it is about 88.888 USD/person (!)
Spain total per capita debt is 83.333 USD/person (2.5 trillion euro -2.5*10^12 euro, 3.75*10^12 USD-) is the private and public combined debt). Spain is one of the countries with most debt per capita (total debt it is not "world wide known" because of huge private debt, so it is somewhat masked).
Socialism? It isn't. Both current goverment ("socialist") and the previous one ("conservative"), are pretty the same: pseudo free market + corruption. Both allowed the bank to pump the finantial and real estate bubbles, for their own interests (corruption, politic finantiation, etc.). Now we're facing the burst of the bubbles, without the possibility of coin devaluation, so is gonna be painful.
1) The 20% I was talking about was about green energy (wind/solar), not nuclear.
2) The low price you point is because it is subsidized, so in the end, paid by the taxpayers. Do you know the debt because of subsidizing the electricity? About 30 billion USD (19 euro billions), for a country of 45 million people, that's 666.66 USD/citizen of debt, growing and paying interest year by year (!)
Disclaimer: I'm a Spanish citizen, living in Spain.
First of all, I want to remark the great work of the REE company ("Red Eléctrica Española" stands for "Spanish Electric Power Network", the monopoly for electric power distribution), they not only do a great work routing and adapting the production to the user energy demand, but also provide a lot of useful information about power consumption, production/consumption balance, etc.
The dark side of the problem is that although there is a huge amount of "green energy" being generated in Spain (wind and solar), that is, paradoxically, a problem. The problem is because current "green electricity production" is above 20% of total energy production, which sounds great, yes, the problem comes from nuclear power being dismantled from past 20 years, so the electric bill goes up because of the more expensive production (the solar energy production is specially expensive, which has been subsidized ad nauseam). Now the country faces near 19% unemployment rates (almost twice the U.S. figures), paying a huge price for energy, with the country in the middle of its worse recession since the post-war era (40's).
The benefit from passing from 8 to 16 general purpose registers is very little, and often, counterproductive, as total "true registers", the ones used for register renaming in OoOE remain the same, so with twice the general purpose registers, you halve the renaming register pool. That was specially noticeable in firsts AMD64 CPUs, and *very* noticeable on Intel Pentium D CPUs (Pentium 4 with x64 support and other minor changes), acusing of insufficient register pool volume for the OoOE operation in x64 mode. Newer CPUs, having a higher pool of registers, have less impact when executing x64 code.
Usually between 10 and 50%, depending on the code.
The moment you start a 32 bit app on a 64 bit system you've got to load the 32 bit version of glibc, as well as every other library the program uses. You'll probably lose more with that than you'll save with the smaller pointers.
That's a very good point. Obviously, in a limited resource context, as the 256MB VPS I pointed before, the optimum is to use a 32-bit OS (it could make sense a 64 bit OS in case you need it for specific 64-bit integer computing or memory mapping related problems).
Having two versions of everything will also take more disk space. On a 10GB limit, an extra 300MB can be quite significant.
So use 64 bit for these cases. The point is not to use or not 64 bit processes, but stop using it when it is unnecessary. As example, on a 20$/month VPS machine (Xen, 256MB, 10GB disk) it could make sense a 64 bit OS, still will 256MB of RAM, but it is stupid to build the utilities in 64 bit mode, because it is a waste of resources (mainly RAM).
Running 32-bit processes on a 64 bit OS makes sense, in order to save memory on "normal" software that doesn't have pointer optimizations in mind (e.g. all software that use pointers instead of indexes).
In my opinion, 32-bit processes it is not only a "must", but also having the tools build in 64-bit mode is a huge error. What's the problem of a 64-bit OS running most processes in 32-bit mode? In the end, there are just few processes that could need more than 2/3GB of memory, and the extra CPU registers doesn't make the difference, yet (1, 2).
I suspect the real cost of Linux support comes from people buying the subsidised console as a cheap cell based computer and not buying any games, meaning Sony makes a loss on those consoles.
Yes, Sony numbers could guess that running Linux could shave the time dedicated for playing (buying) PS3 games, so cutting the possibility, the system is only worth for running PS3 games and cinema.
However, in the other side of the coin, where I am, I'm not willing to buy new Sony devices, at all. Also, as geek, I will encourage to not buy anything from Sony. They are up to cut their products, OK, but I'm free to not buy from them anymore (Sony electronics, Sony entertainment, Columbia Pictures, etc.).
Dear fuckwad, please learn what censorship actually is and stop calling everything you don't like censorship in an attempt to gain notice, you are just lowering the value of the word and making it so more and more people don't give a fuck when you scream censorship.
Please also learn that it is completely acceptable to every normal person on the planet to censor certain things at certain times, regardless your inability to understand that, or the fact that the world doesn't revolve around you.
The censored message (noticed by pjmlp) was a reply from Sarah to a question I made (Why no Linux in PS3 Slim?). The answer -verbatim- it was recovered because of mail lists and by backups: at Slashdot (1), and also in a "repost" in the same PS2-Linux Sony's forum (2, 3).
Message: 51037
BY: aragon
DATE: 2009-Aug-21 06:26
SUBJECT: Why no Linux in PS3 Slim?
Hello,
I've found very disgusting the fact of removing the Other OS option in the PS3 Slim model, and the worst: without explanation. In previous cuts, as it was with the PS2 compatibility it was explained that was in order to cut price, removing PS2 CPU chip first, and PS2 graphic and memory subsistem second, which I found acceptable as explanation.
Why? Is being used unencrypted RAM access or similar? Or is just a plain rip-off?
I know that there are many kind people at Sony Computer Entertainment, so please, if possible, give at least a short explanation of why it has been discontinued the Other OS option in the new PS3s.
Thank you in advance,
aragon
P.S. PS2 Linux user since 2002, and since 2007 for the PS3.
P.S.2. I still can not believe it, what a disgrace.
I'm sorry that you are frustrated by the lack of comment specifically regarding
the withdrawal of support for OtherOS on the new PS3 slim.
The reasons are simple: The PS3 Slim is a major cost reduction involving many
changes to hardware components in the PS3 design. In order to offer the OtherOS
install, SCE would need to continue to maintain the OtherOS hypervisor drivers
for any significant hardware changes - this costs SCE. One of our key objectives
with the new model is to pass on cost savings to the consumer with a lower retail
price. Unfortunately in this case the cost of OtherOS install did not fit with
the wider objective to offer a lower cost PS3.
We'll see if we can get the offical OtherOS page updated with something to this
effect so that an official explanation is provided. Thank you for your comments.
Anyway, if its just a software related point, I hope that it may be addressed
in the future, if users request is enough important for making worth the driver
update effort.
could will be possible for SCE to develop and sell a 'PS3-Slim OtherOS license'?.
since there is a few wannabe/homebrew projects running in PS3 hardware (the
cheapest IBM-cell developer machine), and these projects are dumped to dust
with this major revision of PS3-architectur
With this in mind, I'll agree 1000X is optimistic, but 200-300X certainly wouldn't be for SPEs (again, not accounting for the fact that you have six/seven of them at your disposal), and that's just from a relative asm novice (me) using intrinsics in C/C++ -- not even full blown assembly. Although in this case, I'm more likely to blame the compiler not really knowing what to do for optimization -- there seems to be an insane amount of overhead just twiddling tightly packed data on an architecture that's simply not good at it, whether I need to save space or not. And, understandably, the compiler isn't particularly good at creatively utilizing the colorful instructions available. (Go ahead, look up si_avgb.)
I thought you were speaking about the PS3's PPE processor (PowerPC-64, in-order, two way superscalar, dual threaded), anyway, still 200x is exagerated for the SPE case, being 1000x, 200x, and 300x not optimistic, but impossible. Please excuse the rudeness of my reply.
I've programmed SPEs both in assembly and in C, and the main penalties comes from: 1) the fact that data is always fetched in 128-bit units (16 bytes), despite wanting just one byte, and 2) The SPE has no jump prediction (has 'jump hint' opcodes, to do it manually). Not having data cache is a minor problem, as the SPE local RAM (256KB) runs at half speed of the SPE (1.6GHz vs 3.2GHz), however, because the SPE is pipelined, that it is not a issue, and you can count it as 0 wait state RAM, just like all was cache (similar to the 8/16KB local RAM in Playstation 2 VUs). The difference between "excellent SPE C code" and "excellent SPE assembly code" may be between 3 and 10x, no more, otherwise, your SPE C code it is not that "excellent" (the point is that in C you don't have the 128 registers, but writing aligned code using the 'register' C keyword for avoiding using local variables in the stack, the difference is relatively small, as you can use intrinsics for vector code).
Having 6 SPEs in the PS3 for the game os/linux (from the total 7 in the system), you can have 4 of them running heavily optimized code (most of it in assembly), while having the other 2 running unoptimized code, just because it is not worth optimizing it to the max (e.g. AI, sound, etc. where with one tenth of the CPU power is just enough for the given task).
But trust me when I say that I've seen 1000X speedup by going from excellent C code to highly optimized ASM, which you can only feasibly get by working on a fixed hardware.
Using the same CPU? I don't trust you: It is plain false. In console CPUs (most of them in-order two-way superscalar PowerPC CPUs), for "excellent C code" I understand that already has: loop unrolling, aligned data access, proper packed data structures. In assembly you can add SIMD (up to 4x speedup), data prefetch (up to 2x speedup), but there is no more. Of course, I do not count as speed-up using the PS3's 6 SPEs available for the game, nor the GPU pixel shaders (however, still counting them, you'll reach 50x speed up, no way near your announced 1000x).
I speak from *experience* in x86-64 assembly programming and profiling. Don't you?
In in-order execution CPUs (i.e. not OoOE), such as most ARM CPUs used in phones (not the Cortex OoOE ones), and videogame consoles (R3000, R4400, R5900, PowerPC, PowerPC-64, Cell) there is *huge* advantadge by having 32 registers, because of the total lack of register renaming in the case of primitive ARM and MIPS CPUs, to the light renaming register pool of the modern in-order execution MIPS, ARM, and PowerPC.
Slashdot Mirror
The N900 has actually 256MB of RAM (plus 768 of virtual memory using the flash storage). Previous Nokia models, as the N800 (without telephone, just a tablet PC) had just 128MB of RAM and 256MB of flash. That amount of ram costs below 10 USD. I see no problem for sub 70-150 USD full-fledged Maemo/Linux phones.
Symbian is a pain, underperformer, without possibility of matching Linux or OS X. Nokia it's betting its future, and in my opinion, is Linux.
... please, let Symbian die. The N900 is so much better than any Symbian aberration...
Which assumes NP != P, which is unproven
As it is NP = P. The main handicap for NP = P is to sort the space solution dynamically, without expanding all permutations, avoiding combinatorial explosion. Other problem is that it is not trivial to fragment or address the space within a unexpanded solution for the permutation-space.
Yes.
NP is O( (n^2) * log(n) )
Translation: "Government, companies, and families owe 2.7 trillion, which is about 250% of the Spanish GDP"
Those "2,7 billones" are 2.7*10^12, as in Spain we use the long scale, equals to 2.7 US/UK trillion (short-scale). In USD would be about 4 trillion (not much different from the 3.75 I posted in the previous post), so it is about 88.888 USD/person (!)
666 USD per capita debt just for electricity!
Spain total per capita debt is 83.333 USD/person (2.5 trillion euro -2.5*10^12 euro, 3.75*10^12 USD-) is the private and public combined debt). Spain is one of the countries with most debt per capita (total debt it is not "world wide known" because of huge private debt, so it is somewhat masked).
Socialism? It isn't. Both current goverment ("socialist") and the previous one ("conservative"), are pretty the same: pseudo free market + corruption. Both allowed the bank to pump the finantial and real estate bubbles, for their own interests (corruption, politic finantiation, etc.). Now we're facing the burst of the bubbles, without the possibility of coin devaluation, so is gonna be painful.
"Red" translates for "network", but the meaning of "eléctrica" in a non-literal translation fits better into "electric power", in that context.
1) The 20% I was talking about was about green energy (wind/solar), not nuclear.
2) The low price you point is because it is subsidized, so in the end, paid by the taxpayers. Do you know the debt because of subsidizing the electricity? About 30 billion USD (19 euro billions), for a country of 45 million people, that's 666.66 USD/citizen of debt, growing and paying interest year by year (!)
Disclaimer: I'm a Spanish citizen, living in Spain.
First of all, I want to remark the great work of the REE company ("Red Eléctrica Española" stands for "Spanish Electric Power Network", the monopoly for electric power distribution), they not only do a great work routing and adapting the production to the user energy demand, but also provide a lot of useful information about power consumption, production/consumption balance, etc.
The dark side of the problem is that although there is a huge amount of "green energy" being generated in Spain (wind and solar), that is, paradoxically, a problem. The problem is because current "green electricity production" is above 20% of total energy production, which sounds great, yes, the problem comes from nuclear power being dismantled from past 20 years, so the electric bill goes up because of the more expensive production (the solar energy production is specially expensive, which has been subsidized ad nauseam). Now the country faces near 19% unemployment rates (almost twice the U.S. figures), paying a huge price for energy, with the country in the middle of its worse recession since the post-war era (40's).
The benefit from passing from 8 to 16 general purpose registers is very little, and often, counterproductive, as total "true registers", the ones used for register renaming in OoOE remain the same, so with twice the general purpose registers, you halve the renaming register pool. That was specially noticeable in firsts AMD64 CPUs, and *very* noticeable on Intel Pentium D CPUs (Pentium 4 with x64 support and other minor changes), acusing of insufficient register pool volume for the OoOE operation in x64 mode. Newer CPUs, having a higher pool of registers, have less impact when executing x64 code.
I doubt you'll save much RAM on that.
Usually between 10 and 50%, depending on the code.
The moment you start a 32 bit app on a 64 bit system you've got to load the 32 bit version of glibc, as well as every other library the program uses. You'll probably lose more with that than you'll save with the smaller pointers.
That's a very good point. Obviously, in a limited resource context, as the 256MB VPS I pointed before, the optimum is to use a 32-bit OS (it could make sense a 64 bit OS in case you need it for specific 64-bit integer computing or memory mapping related problems).
Having two versions of everything will also take more disk space. On a 10GB limit, an extra 300MB can be quite significant.
300MB is irrelevant, still when having just 10GB.
So use 64 bit for these cases. The point is not to use or not 64 bit processes, but stop using it when it is unnecessary. As example, on a 20$/month VPS machine (Xen, 256MB, 10GB disk) it could make sense a 64 bit OS, still will 256MB of RAM, but it is stupid to build the utilities in 64 bit mode, because it is a waste of resources (mainly RAM).
Running 32-bit processes on a 64 bit OS makes sense, in order to save memory on "normal" software that doesn't have pointer optimizations in mind (e.g. all software that use pointers instead of indexes).
In my opinion, 32-bit processes it is not only a "must", but also having the tools build in 64-bit mode is a huge error. What's the problem of a 64-bit OS running most processes in 32-bit mode? In the end, there are just few processes that could need more than 2/3GB of memory, and the extra CPU registers doesn't make the difference, yet (1, 2).
Because it is not available in the stores?
In Europe it is not available yet, and it is expected for late October or first week of November.
Wouldn't a PS3 be better suited duo to being an open platform (well, at least as long as the old models are still available)?
Being new PS3 models not able to run Linux, my guess is that Microsoft will push that side in order to attract geeks.
I suspect the real cost of Linux support comes from people buying the subsidised console as a cheap cell based computer and not buying any games, meaning Sony makes a loss on those consoles.
Yes, Sony numbers could guess that running Linux could shave the time dedicated for playing (buying) PS3 games, so cutting the possibility, the system is only worth for running PS3 games and cinema.
However, in the other side of the coin, where I am, I'm not willing to buy new Sony devices, at all. Also, as geek, I will encourage to not buy anything from Sony. They are up to cut their products, OK, but I'm free to not buy from them anymore (Sony electronics, Sony entertainment, Columbia Pictures, etc.).
Dear fuckwad, please learn what censorship actually is and stop calling everything you don't like censorship in an attempt to gain notice, you are just lowering the value of the word and making it so more and more people don't give a fuck when you scream censorship.
Please also learn that it is completely acceptable to every normal person on the planet to censor certain things at certain times, regardless your inability to understand that, or the fact that the world doesn't revolve around you.
It may be "completely acceptable" for you.
Censored thread, recovered from mail list backup:
http://playstation2-linux.com/forum/message.php?msg_id=51037
Message: 51037
BY: aragon
DATE: 2009-Aug-21 06:26
SUBJECT: Why no Linux in PS3 Slim?
Hello,
I've found very disgusting the fact of removing the Other OS option in the PS3 Slim model, and the worst: without explanation. In previous cuts, as it was with the PS2 compatibility it was explained that was in order to cut price, removing PS2 CPU chip first, and PS2 graphic and memory subsistem second, which I found acceptable as explanation.
Why? Is being used unencrypted RAM access or similar? Or is just a plain rip-off?
I know that there are many kind people at Sony Computer Entertainment, so please, if possible, give at least a short explanation of why it has been discontinued the Other OS option in the new PS3s.
Thank you in advance,
aragon
P.S. PS2 Linux user since 2002, and since 2007 for the PS3.
P.S.2. I still can not believe it, what a disgrace.
Removed answer and further replies:
Read and respond to this message at: http://playstation2-linux.com/forum/message.php?msg_id=51038
By: sarahe
Hi aragon,
I'm sorry that you are frustrated by the lack of comment specifically regarding the withdrawal of support for OtherOS on the new PS3 slim.
The reasons are simple: The PS3 Slim is a major cost reduction involving many changes to hardware components in the PS3 design. In order to offer the OtherOS install, SCE would need to continue to maintain the OtherOS hypervisor drivers for any significant hardware changes - this costs SCE. One of our key objectives with the new model is to pass on cost savings to the consumer with a lower retail price. Unfortunately in this case the cost of OtherOS install did not fit with the wider objective to offer a lower cost PS3.
We'll see if we can get the offical OtherOS page updated with something to this effect so that an official explanation is provided. Thank you for your comments.
Sarah.
- - - - - - - -
Read and respond to this message at: http://playstation2-linux.com/forum/message.php?msg_id=51039 By: aragon
Thank you very much for the answer, Sarah.
Anyway, if its just a software related point, I hope that it may be addressed in the future, if users request is enough important for making worth the driver update effort.
Best regards,
aragon
- - - - - - - -
Read and respond to this message at: http://playstation2-linux.com/forum/message.php?msg_id=51040
By: f5inet
Thanks for the extra-official explain, sarahe.
could will be possible for SCE to develop and sell a 'PS3-Slim OtherOS license'?. since there is a few wannabe/homebrew projects running in PS3 hardware (the cheapest IBM-cell developer machine), and these projects are dumped to dust with this major revision of PS3-architectur
Don't count on my for new PS3 "Slim" until it become able to run Linux again, you insensitive clods!
With this in mind, I'll agree 1000X is optimistic, but 200-300X certainly wouldn't be for SPEs (again, not accounting for the fact that you have six/seven of them at your disposal), and that's just from a relative asm novice (me) using intrinsics in C/C++ -- not even full blown assembly. Although in this case, I'm more likely to blame the compiler not really knowing what to do for optimization -- there seems to be an insane amount of overhead just twiddling tightly packed data on an architecture that's simply not good at it, whether I need to save space or not. And, understandably, the compiler isn't particularly good at creatively utilizing the colorful instructions available. (Go ahead, look up si_avgb.)
I thought you were speaking about the PS3's PPE processor (PowerPC-64, in-order, two way superscalar, dual threaded), anyway, still 200x is exagerated for the SPE case, being 1000x, 200x, and 300x not optimistic, but impossible. Please excuse the rudeness of my reply.
I've programmed SPEs both in assembly and in C, and the main penalties comes from: 1) the fact that data is always fetched in 128-bit units (16 bytes), despite wanting just one byte, and 2) The SPE has no jump prediction (has 'jump hint' opcodes, to do it manually). Not having data cache is a minor problem, as the SPE local RAM (256KB) runs at half speed of the SPE (1.6GHz vs 3.2GHz), however, because the SPE is pipelined, that it is not a issue, and you can count it as 0 wait state RAM, just like all was cache (similar to the 8/16KB local RAM in Playstation 2 VUs). The difference between "excellent SPE C code" and "excellent SPE assembly code" may be between 3 and 10x, no more, otherwise, your SPE C code it is not that "excellent" (the point is that in C you don't have the 128 registers, but writing aligned code using the 'register' C keyword for avoiding using local variables in the stack, the difference is relatively small, as you can use intrinsics for vector code).
Having 6 SPEs in the PS3 for the game os/linux (from the total 7 in the system), you can have 4 of them running heavily optimized code (most of it in assembly), while having the other 2 running unoptimized code, just because it is not worth optimizing it to the max (e.g. AI, sound, etc. where with one tenth of the CPU power is just enough for the given task).
But trust me when I say that I've seen 1000X speedup by going from excellent C code to highly optimized ASM, which you can only feasibly get by working on a fixed hardware.
Using the same CPU? I don't trust you: It is plain false. In console CPUs (most of them in-order two-way superscalar PowerPC CPUs), for "excellent C code" I understand that already has: loop unrolling, aligned data access, proper packed data structures. In assembly you can add SIMD (up to 4x speedup), data prefetch (up to 2x speedup), but there is no more. Of course, I do not count as speed-up using the PS3's 6 SPEs available for the game, nor the GPU pixel shaders (however, still counting them, you'll reach 50x speed up, no way near your announced 1000x).
I speak from *experience* in x86-64 assembly programming and profiling. Don't you?
In in-order execution CPUs (i.e. not OoOE), such as most ARM CPUs used in phones (not the Cortex OoOE ones), and videogame consoles (R3000, R4400, R5900, PowerPC, PowerPC-64, Cell) there is *huge* advantadge by having 32 registers, because of the total lack of register renaming in the case of primitive ARM and MIPS CPUs, to the light renaming register pool of the modern in-order execution MIPS, ARM, and PowerPC.