I don't know the specifics for the G5s, but at my work we found that when using Visual C++ for Windows code, it ran faster to optimise for size instead of speed.
We theorized that it was a combination of cache and swapping, since our binaries were quite large.
The point is that I wouldn't make too many assumption based on what optimisation settings anyone uses on any architecture.
Marketing studies show that when given too any choices people fall back to whichever brand name is most recognisable to them. Hence branding of commodities like carbonated drinks, etc.
Potentially what Sony is really saying is that the more choices they present to the user, the more likely that Sony's strong brand name will give them the sale.
Most likely the devices shouldn't just notify the user of repairing, but prompt for the PIN then as well.
Right now, it appears that:
First pairing: Request PIN -> Have stored PIN -> Make that long internal code Subsequent pairing: Have stored PIN -> Make that long internal code
If they just removed the optimisation of storing the PIN, then it would be more secure. Plus since there'd be no need to store it, then if you lost your phone no one could extract the PIN, which may well be the same as your banking PIN, etc.
That, along with longer PINs would thwart most attacks.
But, in the physical world, there are degrees of separation of privacy. If I'm at home I have the most privacy. If I go out into public, I have less privacy. Typically, to commit a crime, one must leave one's own property, and invade another's. The resulting reduction of privacy when doing so, facilitates capturing criminals.
You are advocating the creation of software which will allow others to interact, at a distance, with privacy. That's not something the real world gives, but is an escalation of cababilties. Along with those greater capabilties, I argue, there is an increased responsibility. But no, you would put these tools into everyone's hands, which inevitably includes those who would use it to facilitate their harming others.
Ok, so guns don't kill people, people do... A tool is a tool... Personal responsibility... etc.
Right, but we already know about the problem of pedophiles and freenet. Also, we're not talking about a simple file trading program where a file only goes from Bob to Joe. We're talking about a protocol designed to disseminate software from one source to as many people as possible. Ie from the abuser to all the sick fucks who watch, while protected the abuser from the police.
All so you can steal some copy righted material.
You're trying to solve a problem, with this much illegality: |___| by creating tools that facilitate this much illegality: |____________________________________ ______|
That's where your personal responsibility kicks in.
As for my being naive, or watching CNN, or whatever BS you pulled out of your ass...
I'm not saying that your software would make any more pedophiles, or that the Internet makes more pedophiles, I'm saying that your software would protect existing ones, who would otherwise get caught. Them being protected means they can continue their activities. Hence, it would cause harm.
I don't expect you to emotionally care, but I do expect you to not be so fucking stupid, and to maybe consider the affects of one's actions, and take responsibility for them.
All you people who are worried that the RIAA or MPAA might sue you, or that some "thought police" might come after you, are creating the tools for pedophiles to use to evade capture. We're talking about people who are harming kids today, for real.
All so you can save a few bucks on some CD or DVD.
I blame the RIAA and MPAA too, for creating this bullshit scenario, but you guys should own up to the reprocussions of your own actions.
Sorry, I should have previewed, but I didn't, so I never noticed that my C++ templates got confused for html tags, and a whole block of code is just gone.
What the code was trying to illustrate was the simple fact that most procedural code uses parallel arrays, whereas most structured and OOP code use structures/classes. The big difference is that large arrays of same typed data tend to work better in SIMD units, and pack better for alignment, using less memory, and thus cache. Structures/classes, on the other hand, are easier for programmers, and less error-prone. So, I'm not really talking about the code, so much as how the data is handled.
As to whether programming is a science or an art, I think that misses the fact that science and art overlap a lot. Both employ theory, experimentation, and a feedback loop of gained experience. In fact, I challenge anyone to show a difference between the two.
Perhapse, in science, there is less focus on aesthetics.
Where is the line between an artist and an artisan? Is one less of an artist for making duplicates than making originals? What if the duplicates are better than the originals? Are commercial artists not artists?
I think there's a range of careers and products and creativity in art and science, and for that matter in any job. So, does that have any impact on whether something is art or science?
I think that procedural code would run better on the SPEs than OOP or functional code.
Basically the SPEs are stripped down CPUs like a PPC. Code has to be loaded into it, and then it streams in data from its bus, works on the data, and then the results stream out to the bus.
So, you're not going to throw little bits of code and data at it, like offloading some functional lazy evaluations, but rather would setup an algorithm, and then pump data at it. In theory the data could be arranged in a structured or OOP fashion, but probably it would run best to just have big arrays of stuff.
Procedural data example:
float a[MAX];
float b[MAX];
float c[MAX];
for(int i = 0; i xyz(MAX);
for(Vector::iterator i = xyz.begin(); i != xyz.end(); i++)
i.get().do();
When you look at the assembly differences, the OOP code has way more overhead to do the same thing. Plus, simple things like data alignment in arrays versus structures (classes) can make a big difference too.
Also, since each SPE doesn't have much local RAM, it wouldn't have much RAM for stack space, so recursion would not be ideal. One more strike against functional languages.
As well, most functional languages use a VM of some sort to keep all the state info that imperative languages lose upon compilation. That too wouldn't fit easily in the SPE's RAM.
Your sum[1...10] example is a little too simple to bother parallelising. A better example would be to sum the results of a series of method invocations.
int calculateTotalHours()
int totalHours = 0;
for(int i = 0; i _list.size(); i++) {
Employee e = _list.get( i );
totalHours += e.calculateHours();
}
return totalHours; }
Ok, this is a horribly botched example of the same thing in haskell:
calculateTotalHours::[] = 0 calculateTotalHours::list = calculateTotalHours head list + calculateTotalHours tail list calculateTotalHours::Employee e = calculateHours e
The idea is that you don't use looping, but rather use recursion. An expression matches a pattern. So, when we pass a list to calculateTotalHours, it takes the first Employee, and gets the hours from it, and adds that to the result of recursing over the rest of the list. The [] matches the empty list, which just returns zero, and bottoms out the recursion. This is much slower than just iterating with a for loop, but has some advantages. First off, everything is lazily evaluated, so we only find the result when it's actually needed, not right away. Secondly, instead of recursing, the runtime could split each calculation for each employee off into a separate thread or CPU, or machine on the network.
Sorry but I don't have access to the generic algorithm.
But, the point is that functional languages state things at a sufficiently high level, that they can be easily optimised. One of those optimisations is parallelism, but there are others, such as this math example.
In an imperative language, the programmer might code up a for loop with summation, which could only be optimised by unrolling the loop and using autovectorisation. A functional language might sidestep the whole loop, as above, or use paralellism, or do the autovectorisation too. In theory it could do whichever is best, decided at runtime, from criteria specific to your computing environment.
Of course, I said "in theory" since most functional languages are not all that optimised in reality, so they're just slower.
Fugitsu and Sun are merging their two SPARC implementations (Sparc64 and UltraSparc). Since Fugitsu's Sparc64 was usually better/faster, I expect Sun's Sparc offerings to improve in the next few years.
I don't think the SPEs can be effectively preemptively scheduled. They are designed to have executable code loaded onto them, and work on buffer blocks of data. A context switch would have to load both code, SPE CPU state, and buffer data.
What's more likely is for them to be cooperatively scheduled. SPE code could signal when it's done a block.
Actually, now that I think about it, there's a central memory manager module, which handles transfering data to and from SPEs. Potentially the Cell could build a dependency map of how the buffer blocks feed through the SPEs, and detect when more data is coming from system RAM, and start the context switch then.
RAM -> SPE0 -> SPE5 -> SPE2 -> RAM
The main CPU would build metrics to see how long each SPE takes to process a block of data, so when it's near time to context switch, it could wait for the next copy of data from RAM to SPE0, at which point it would stop not let the copy happen. When all of the old data was done copying from SPE0 to SPE5, then SPE0 could be context switched away. Similarly when SPE5 was done processing its data, and had copied it to SPE2, then it would be context switched, and so on.
Instead of thinking of all of the SPEs as part of one process, that would be preemptively scheduled together, think of them as separate threads that would be independantly scheduled, but whose dependancies would provide hints as to the best time to context switch them each.
I have no idea what James Gosling or whoever at Sun meant when they made Java, but I know that a lot of server side communication, between heterogeneous hosts, assumes that Serialization works portably.
The only caveat that I know of is that between Java 1.1.x and Java 1.2.x the Serialization format changed, to allow for new functionality.
Or perhaps you're thinking of the Swing API which does not guarrantee any portability of its Serialisation at all, such as even between different version of the same JVM.
To be fair, some of the maritime provinces are only beggars because the federal government keeps their resource income, unlike Alberta, which keeps a lot of its oil revenue.
This is supposed to now change, so I expect that dynamic to change over the next 5 years.
My Dad's favorite story, that he tells to everyone, is about how, when I was 4, I was washing the dishes, and asked for a break, so he let me vacuum for a while, and then I went back to doing dishes.
Let's take a look at how DJVU adds little or nothing beyond PDF, and so you comment is obviously overenthusiastic.
1. PDF supports compressible object streams, so complete objects and their metadata can now be compressed. Not all viewers support this, and apparently OS X Preview only adds support for this with OS X 10.4. So BZZ adds nothing.
2. PDF supports JPEG2000 which is a better supported standard than DjVuPhoto.
3. PDF supports JBIG2 (which supercedes CCITT Group 4 Fax encoding) which you call DjVuBitonal (aka JB2).
4. PDF supports any degree of complexity of mixing images and drawing commands, at any alpha level, which is better than restricting drawing commands to be on top of images, as with DjVuDocument.
So yes, I commend DJVU for its ability to come up with a plainer, more restricted, less standard format than PDF. But please, spare us the: DJVU is more like PDF should have been.
Slashdot Mirror
I don't know the specifics for the G5s, but at my work we found that when using Visual C++ for Windows code, it ran faster to optimise for size instead of speed.
We theorized that it was a combination of cache and swapping, since our binaries were quite large.
The point is that I wouldn't make too many assumption based on what optimisation settings anyone uses on any architecture.
Marketing studies show that when given too any choices people fall back to whichever brand name is most recognisable to them. Hence branding of commodities like carbonated drinks, etc.
Potentially what Sony is really saying is that the more choices they present to the user, the more likely that Sony's strong brand name will give them the sale.
Don't moderate flamebait as "Troll" they are distinct. Know the difference or get Meta-moderated.
What is the difference?
A lot of the time, if you change where an old person lives, then they die. There is no financial compensation for being killed, against your will.
I wasn't disagreeing with you, so much as I was taking a jab at Sun.
Moore's Law does not apply to Sun's SPARC chips.
Hey, we also drink Tim Horton's coffee!
Most likely the devices shouldn't just notify the user of repairing, but prompt for the PIN then as well.
Right now, it appears that:
First pairing: Request PIN -> Have stored PIN -> Make that long internal code
Subsequent pairing: Have stored PIN -> Make that long internal code
If they just removed the optimisation of storing the PIN, then it would be more secure. Plus since there'd be no need to store it, then if you lost your phone no one could extract the PIN, which may well be the same as your banking PIN, etc.
That, along with longer PINs would thwart most attacks.
First off, I want everyone's privacy protected.
_ ______|
But, in the physical world, there are degrees of separation of privacy. If I'm at home I have the most privacy. If I go out into public, I have less privacy. Typically, to commit a crime, one must leave one's own property, and invade another's. The resulting reduction of privacy when doing so, facilitates capturing criminals.
You are advocating the creation of software which will allow others to interact, at a distance, with privacy. That's not something the real world gives, but is an escalation of cababilties. Along with those greater capabilties, I argue, there is an increased responsibility. But no, you would put these tools into everyone's hands, which inevitably includes those who would use it to facilitate their harming others.
Ok, so guns don't kill people, people do... A tool is a tool... Personal responsibility... etc.
Right, but we already know about the problem of pedophiles and freenet. Also, we're not talking about a simple file trading program where a file only goes from Bob to Joe. We're talking about a protocol designed to disseminate software from one source to as many people as possible. Ie from the abuser to all the sick fucks who watch, while protected the abuser from the police.
All so you can steal some copy righted material.
You're trying to solve a problem, with this much illegality:
|___|
by creating tools that facilitate this much illegality:
|___________________________________
That's where your personal responsibility kicks in.
As for my being naive, or watching CNN, or whatever BS you pulled out of your ass...
I'm not saying that your software would make any more pedophiles, or that the Internet makes more pedophiles, I'm saying that your software would protect existing ones, who would otherwise get caught. Them being protected means they can continue their activities. Hence, it would cause harm.
I don't expect you to emotionally care, but I do expect you to not be so fucking stupid, and to maybe consider the affects of one's actions, and take responsibility for them.
No, that's the last thing we need.
All you people who are worried that the RIAA or MPAA might sue you, or that some "thought police" might come after you, are creating the tools for pedophiles to use to evade capture. We're talking about people who are harming kids today, for real.
All so you can save a few bucks on some CD or DVD.
I blame the RIAA and MPAA too, for creating this bullshit scenario, but you guys should own up to the reprocussions of your own actions.
Sorry, I should have previewed, but I didn't, so I never noticed that my C++ templates got confused for html tags, and a whole block of code is just gone.
What the code was trying to illustrate was the simple fact that most procedural code uses parallel arrays, whereas most structured and OOP code use structures/classes. The big difference is that large arrays of same typed data tend to work better in SIMD units, and pack better for alignment, using less memory, and thus cache. Structures/classes, on the other hand, are easier for programmers, and less error-prone. So, I'm not really talking about the code, so much as how the data is handled.
As to whether programming is a science or an art, I think that misses the fact that science and art overlap a lot. Both employ theory, experimentation, and a feedback loop of gained experience. In fact, I challenge anyone to show a difference between the two.
Perhapse, in science, there is less focus on aesthetics.
Where is the line between an artist and an artisan? Is one less of an artist for making duplicates than making originals? What if the duplicates are better than the originals? Are commercial artists not artists?
I think there's a range of careers and products and creativity in art and science, and for that matter in any job. So, does that have any impact on whether something is art or science?
Apparently most of my whole OOP section got stripped out because template signs are like html tags... So if this makes no sense, then sorry.
I think that procedural code would run better on the SPEs than OOP or functional code.
Basically the SPEs are stripped down CPUs like a PPC. Code has to be loaded into it, and then it streams in data from its bus, works on the data, and then the results stream out to the bus.
So, you're not going to throw little bits of code and data at it, like offloading some functional lazy evaluations, but rather would setup an algorithm, and then pump data at it. In theory the data could be arranged in a structured or OOP fashion, but probably it would run best to just have big arrays of stuff.
Procedural data example:
float a[MAX];
float b[MAX];
float c[MAX];
for(int i = 0; i xyz(MAX);
for(Vector::iterator i = xyz.begin(); i != xyz.end(); i++)
i.get().do();
When you look at the assembly differences, the OOP code has way more overhead to do the same thing. Plus, simple things like data alignment in arrays versus structures (classes) can make a big difference too.
Also, since each SPE doesn't have much local RAM, it wouldn't have much RAM for stack space, so recursion would not be ideal. One more strike against functional languages.
As well, most functional languages use a VM of some sort to keep all the state info that imperative languages lose upon compilation. That too wouldn't fit easily in the SPE's RAM.
Your sum[1...10] example is a little too simple to bother parallelising. A better example would be to sum the results of a series of method invocations.
int calculateTotalHours()
int totalHours = 0;
for(int i = 0; i _list.size(); i++) {
Employee e = _list.get( i );
totalHours += e.calculateHours();
}
return totalHours;
}
Ok, this is a horribly botched example of the same thing in haskell:
calculateTotalHours::[] = 0
calculateTotalHours::list = calculateTotalHours head list + calculateTotalHours tail list
calculateTotalHours::Employee e = calculateHours e
The idea is that you don't use looping, but rather use recursion. An expression matches a pattern. So, when we pass a list to calculateTotalHours, it takes the first Employee, and gets the hours from it, and adds that to the result of recursing over the rest of the list. The [] matches the empty list, which just returns zero, and bottoms out the recursion. This is much slower than just iterating with a for loop, but has some advantages. First off, everything is lazily evaluated, so we only find the result when it's actually needed, not right away. Secondly, instead of recursing, the runtime could split each calculation for each employee off into a separate thread or CPU, or machine on the network.
sum[1...10] =
1 + 10 +
2 + 9 +
3 + 8 +
4 + 7 +
5 + 6 =
11 + 11 + 11 + 11 + 11 =
(10/2)(10+1)
Sorry but I don't have access to the generic algorithm.
But, the point is that functional languages state things at a sufficiently high level, that they can be easily optimised. One of those optimisations is parallelism, but there are others, such as this math example.
In an imperative language, the programmer might code up a for loop with summation, which could only be optimised by unrolling the loop and using autovectorisation. A functional language might sidestep the whole loop, as above, or use paralellism, or do the autovectorisation too. In theory it could do whichever is best, decided at runtime, from criteria specific to your computing environment.
Of course, I said "in theory" since most functional languages are not all that optimised in reality, so they're just slower.
Fugitsu and Sun are merging their two SPARC implementations (Sparc64 and UltraSparc). Since Fugitsu's Sparc64 was usually better/faster, I expect Sun's Sparc offerings to improve in the next few years.
I don't think the SPEs can be effectively preemptively scheduled. They are designed to have executable code loaded onto them, and work on buffer blocks of data. A context switch would have to load both code, SPE CPU state, and buffer data.
What's more likely is for them to be cooperatively scheduled. SPE code could signal when it's done a block.
Actually, now that I think about it, there's a central memory manager module, which handles transfering data to and from SPEs. Potentially the Cell could build a dependency map of how the buffer blocks feed through the SPEs, and detect when more data is coming from system RAM, and start the context switch then.
RAM -> SPE0 -> SPE5 -> SPE2 -> RAM
The main CPU would build metrics to see how long each SPE takes to process a block of data, so when it's near time to context switch, it could wait for the next copy of data from RAM to SPE0, at which point it would stop not let the copy happen. When all of the old data was done copying from SPE0 to SPE5, then SPE0 could be context switched away. Similarly when SPE5 was done processing its data, and had copied it to SPE2, then it would be context switched, and so on.
Instead of thinking of all of the SPEs as part of one process, that would be preemptively scheduled together, think of them as separate threads that would be independantly scheduled, but whose dependancies would provide hints as to the best time to context switch them each.
I have no idea what James Gosling or whoever at Sun meant when they made Java, but I know that a lot of server side communication, between heterogeneous hosts, assumes that Serialization works portably.
The only caveat that I know of is that between Java 1.1.x and Java 1.2.x the Serialization format changed, to allow for new functionality.
Or perhaps you're thinking of the Swing API which does not guarrantee any portability of its Serialisation at all, such as even between different version of the same JVM.
This particular scene used a security camera in a lingerie store. I saw it on TV yesterday, which is why I know, not because I'm a freak :)
Enemy of the State had a scene where they panned around to see the other side of someone. It pained me greatly.
To be fair, some of the maritime provinces are only beggars because the federal government keeps their resource income, unlike Alberta, which keeps a lot of its oil revenue.
This is supposed to now change, so I expect that dynamic to change over the next 5 years.
Or just hack the PS3 to run Linux...
My Dad's favorite story, that he tells to everyone, is about how, when I was 4, I was washing the dishes, and asked for a break, so he let me vacuum for a while, and then I went back to doing dishes.
Wasn't that supposed to happen when Word docs went XML?
Let's take a look at how DJVU adds little or nothing beyond PDF, and so you comment is obviously overenthusiastic.
1. PDF supports compressible object streams, so complete objects and their metadata can now be compressed. Not all viewers support this, and apparently OS X Preview only adds support for this with OS X 10.4. So BZZ adds nothing.
2. PDF supports JPEG2000 which is a better supported standard than DjVuPhoto.
3. PDF supports JBIG2 (which supercedes CCITT Group 4 Fax encoding) which you call DjVuBitonal (aka JB2).
4. PDF supports any degree of complexity of mixing images and drawing commands, at any alpha level, which is better than restricting drawing commands to be on top of images, as with DjVuDocument.
So yes, I commend DJVU for its ability to come up with a plainer, more restricted, less standard format than PDF. But please, spare us the: DJVU is more like PDF should have been.