FYI: Visa charges different rates depending on the level of security. This applies both to the level of electronic checking you do before accepting the card as well as whether or not you require a signature.
For example, if your credit network is down, and you accept a card anyway for a low amount transaction, you'll pay a higher fee. (Most brick and mortar retailers will do this.)
In addition to all this, security measures, including the signature, are for the protection of the merchant. If the signature is not valid, it is the merchant who ends up eating the transaction. Unfortuantely, many brick-and-mortar merchants think of this as "the cost of doing business" and don't bother to really check signatures. Obviously much the same applies online.
Anyway, presumably Visa would charge a lower rate if digital signatures were used, as it would reduce fraud. And, of course, the retailers would suffer less fraud.
Well, I think that's half of it. Yes, you are right about the busy desktop being half of the problem with WinCE. But the other half was the size of the OS. It meant bigger memory requirements, which meant higher cost.
One difficulty which I think you may have missed is that PDAs are almost always graphical devices. The Palm certainly is. And obviously X Windows is far too large to fit on a PDA. (And has far too much unneeded functionality.
A true CLI is a royal pain in the ass with only a stylus.
I'm sure it could be done. I just suspect that by the time you through out everything that wasn't needed on a PDA, and added in extra things that were needed. (Some sort of Grafitti version, a simple graphics interface, etc.) you'd end up with something that wasn't particularly compatible with mainstream Linux, and was bigger than something written from the ground up.
It probably depends on what sort of embedded device you are looking at. If you are looking for a real computing platform, it might be a good idea. But do you really need multitasking on something like a palm-pilot? Users? A file-system, even? If not, then why Linux?
I can't help but wonder of an embedded-linux will have problems similar to WinCE. A large OS crammed into a too-small package.
Is it wrong to wonder if, perhaps, we might be better off having different OSes that serve different purposes? Do we have to have only one, jack-of-all-trades OS?
Anyway, there is a reason that PalmOS beat WinCE, and it wasn't necessarily the normal Microsoft bugginess. It was the fact that PalmOS just does what is needed, and doesn't have a bunch of extra fluff brought down from bigger machines. Would an embedded-linux be any different?
Re:Out of the Real World
on
On to Mars
·
· Score: 2
The trouble with this argument is that assumes that the reason people are starving is lack of money. This is not true. Currently, we produce more than enough food to feed everyone. Hell, the US still pays some farmers not to grow and often food rots in silos for lack of a good price.
The problem that causes starvation is not lack money. It is politics. Politics both in the countries that have food, and also in the countries that don't.
Perhaps it is not sex, but age. To some of us old farts, the Commodore PET is "News for Nerds". Hell, that box is what made me a geek in the first place.
Yes, but the key is that if you allocate from the heap, you have to search some sort of free memory chain to find something. This takes time. To allocate something off of the stack, you just increase the stack pointer.
If you do benchmarks, you'll find that this (At least, you would have last I checked, which was with an old DOS compiler):
Foobar f1(1,2,3);
is dramatically faster than this:
Foobar* f1 = new Foobar(1,2,3);
for the reasons mentioned above.
This is because the former looks something like this in psuedocode:
f1 = StackPtr StackPtr += sizeof(Foobar) f1.Constructor(1,2,3)
while the latter generates something like:
Start at beginning of free block chain for each block is it big enough? if so, is it too big? if so, split it and return beginning otherwise return it
f1 = returned block f1.Constructor(1,2,3)
Where this really gets compelling is if you a class has member classes which have member classes, if those members are all allocated, you end up with lots of little chunks of memory. On the other hand, if they are all regular members, and not pointers to things that are allocated, they just become part of the parent object's size.
If you have this:
class A { class B {} b; class C {} c; };
then this line gets memory from the stack merely by incrementing the stack pointer by sizeof(A):
A a;
This is basically one assembly op which, unless there is a page fault, is nothing, timewise. On the other hand, this:
class A { class B {} *b = new B; class C {} *c = new C; };
Created like this:
A *a = new A;
Requires three searchs through the heap to find memory. Not only will this take more time, but this is more likely to generate a page fault, both because you might not find contiguous memory, but also because each heap object has overhead associated with it (the list of free and used memory blocks) while each stack object usually does not.
(The other reason to prefer the former sort of class is that even if you decide to use the heap for the owning class, you use a bigger chunk, allocating only once for the class rather than for each memory object.)
Which is why the compiler (or in the alloca() case, the programmer) has to be smart enough to know not to return a reference (or assign it to a global, etc.).
Would you also send your pointers across a network and expect them to work at the other end?
The idiots who wrote the code that caused me the pain would have...
This involves one of the internal debates I've had about C for years. C allows you to shoot yourself in the foot. That is all well and good as I (I hope) know what I'm doing. The trouble is that, with turnover in this industry what it is, a new foot might have arrived by the time the bullet hits. (Unfortunately, I've often been the new foot.)
One huge advantage C++ has here is that you can declare on object on the stack. This makes your fourth bullet go away and turns the second bullet into something like two asm instructions.
(And, of course, there is no bytecode to load, so the first bullet becomes merely "call the constructor", whether the stack or the heap is used.)
Even in C++, the heap is overused. With moderately careful design, the majority of objects can be left on the stack. I'm convinced that one of the reasons that people think C++ is so much slower than C is that many C++ programmers don't think about this enough.
Calls the hierachy of constructors of all Foos superclasses. Quite slow.
What strikes me here is that part of the problem is these huge object hierarchies that people seem to love so much. A very flat hierarchy reduces this quite a bit.
Or maybe it only bothers to do this when resources get tight. Perhaps another malloc comes along wanting the same size (roughly) as the thing just freed. We just give it the recently freed chunk. We then don't have to build a new one.
Caveat: I have no idea if this makes sense, performance-wise, in the real world.
If you kept the entire compiled code around (and not just part of it), you could keep profiling info, and only attempt further optimization the Nth time a block was run in a certain period, were N is some sufficiently high number. You could also be really smart and save the compiled code so that next time you execute, you don't need to recompile everything.
Imagine a program that speeds up the more times you run it...
Perhaps you could set some sort of "optimization threshold", which limits the percentage of time the system tries to improve over time. The first time you run, there is the complete overhead of compiling. The second and subsequent times, a 10% slowdown for optimization. After a few runs, with the data collected, the performance improvement beats the 10% overhead and you are better off.
I think that what he is saying is that sometimes you could gain a lot of speed in java by allocating on the stack. This has been one of my biggest problems with Java, the way everything is done in the heap, not the stack. If an object is only used in one function, (or functions it calls) it makes perfect sense to put it on the stack, not the heap.
(I'd post an example, but I'm not a Java guy, and don't want to screw up my syntax in public.)
I used to do something like this in C, manually. Suppose you have this:
void Foo(int y) { char *Bar=malloc(y);
/*dostuff*/
free(Bar); }
With some compilers, you can save time and avoid memory leaks by allocating on the stack like this:
void Foo(int y) { char *Bar=alloca(y);/* Compiles roughly to Bar=sp, sp+=y (or is it sp-=y?)*/
/*dostuff*/
/*No free needed, popped off of stack.*/ }
I'd think that if a Java optimizer were smart enough to know when to do this, it'd speed things up tremendously for some programs.
The trouble is that you can't always use sizeof() and you can't always change your types around. The classic case (which I ran into, painfully) is when you have two different machines with two different architectures passing structures around.
It is easy enough to define a structure like this:
struct { int Foo1; int Foo2; };
and yes, regardless of the machine, this will compile and run most anywhere, assuming that Foo1 and Foo2 are never larger than 2^15. The trouble is, if you are using that structure two places, one on an 8-bit machine, another on a system that is being upgraded from a 16-bit OS to a 32 bit OS, well, you have pain. (An unfortunately all too real situation I got stuck with.)
Now in my situation, you can certainly say that the idiot authors should have used shorts (and they should have), but even then, there is no guarantee that a short will be the same size in both places. I foresee a lot of pain when sizeof(long) stops equalling sizeof(int) as we move to 64 bits.
So what you end up doing is having the structure defined twice, potentially differently, for each side of the pipe. Not fun to maintain.
Here's something to really wierd yourself out thinking about:
Suppose you were able to create a perfect working replica of your brain. (Perhaps electronic, but functionally the same, including timings.) Now suppose you take this new working replica, download the "software", cut it in half, cut your brain in half, and create two half electronic/half gray matter brains.
95% of my CD listening is at a PC. If I can't use the CD in a CD-ROM, it is just a useless hunk of plastic, little better than an AOL disk.
I'd say this calls for a boycott, but why bother? They're products are useless. Obviously, no one is going to buy a useless product.
And looking around the office, and seeing the number of headphones hooked into computers, I'd say that they've grossly underestimated the impact of this. And we're not talking about just techies, either.
Anyone got an e-mail for BMG so that I can inform them that they are starting to produce products that are useless to me?
Slashdot Mirror
FYI: Visa charges different rates depending on the level of security. This applies both to the level of electronic checking you do before accepting the card as well as whether or not you require a signature.
For example, if your credit network is down, and you accept a card anyway for a low amount transaction, you'll pay a higher fee. (Most brick and mortar retailers will do this.)
In addition to all this, security measures, including the signature, are for the protection of the merchant. If the signature is not valid, it is the merchant who ends up eating the transaction. Unfortuantely, many brick-and-mortar merchants think of this as "the cost of doing business" and don't bother to really check signatures. Obviously much the same applies online.
Anyway, presumably Visa would charge a lower rate if digital signatures were used, as it would reduce fraud. And, of course, the retailers would suffer less fraud.
Well, I think that's half of it. Yes, you are right about the busy desktop being half of the problem with WinCE. But the other half was the size of the OS. It meant bigger memory requirements, which meant higher cost.
One difficulty which I think you may have missed is that PDAs are almost always graphical devices. The Palm certainly is. And obviously X Windows is far too large to fit on a PDA. (And has far too much unneeded functionality.
A true CLI is a royal pain in the ass with only a stylus.
I'm sure it could be done. I just suspect that by the time you through out everything that wasn't needed on a PDA, and added in extra things that were needed. (Some sort of Grafitti version, a simple graphics interface, etc.) you'd end up with something that wasn't particularly compatible with mainstream Linux, and was bigger than something written from the ground up.
It probably depends on what sort of embedded device you are looking at. If you are looking for a real computing platform, it might be a good idea. But do you really need multitasking on something like a palm-pilot? Users? A file-system, even? If not, then why Linux?
If you had it to do all over again, would you still do it, know the (unfair) legal mess it would land you in?
I can't help but wonder of an embedded-linux will have problems similar to WinCE. A large OS crammed into a too-small package.
Is it wrong to wonder if, perhaps, we might be better off having different OSes that serve different purposes? Do we have to have only one, jack-of-all-trades OS?
Anyway, there is a reason that PalmOS beat WinCE, and it wasn't necessarily the normal Microsoft bugginess. It was the fact that PalmOS just does what is needed, and doesn't have a bunch of extra fluff brought down from bigger machines. Would an embedded-linux be any different?
The trouble with this argument is that assumes that the reason people are starving is lack of money. This is not true. Currently, we produce more than enough food to feed everyone. Hell, the US still pays some farmers not to grow and often food rots in silos for lack of a good price.
The problem that causes starvation is not lack money. It is politics. Politics both in the countries that have food, and also in the countries that don't.
nerd
You say that like it's a bad thing.
Sorry, prior art. I wrote mine before tthe Sinclair even existed!
Perhaps it is not sex, but age. To some of us old farts, the Commodore PET is "News for Nerds". Hell, that box is what made me a geek in the first place.
That was the first computer I ever used...
I was forteen years old, and my uncle, a Hewlett-Packard engineer, lent us one for a few months.
Ironic that playboy brings up where I lost my technical virginity.
I still remember the first program I ever wrote:
10 A=1
20 print A
30 LET A = A + 1
40 GOTO 20
It also had the first bug I ever found, as it printed something like:
1.00000
2.00000
3.00000
3.99999
5.00000
6.00000
(Floating point was still problematic back then.)
Oh, crap! I mean crackers...
How is he supposed to decrypt this information anyways. With an abacus? pen and paper? After all he's restricted from practically all computer use.
He's not restricted from giving it to someone else...
Even hackers have friends.
If I were Mitnick, I would have written and run the following program:
FILE*fp=fopen("SuperSecretEncryptedStuff", "a+");
for(long i=0;i1000000000L;i++)
{
unsigned char c=rand()%0xff;
fwrite(&c,1,1,fp);
}
fclose(fp);
It would give me something to laugh about as I sat in my cell.
Yes, but the key is that if you allocate from the heap, you have to search some sort of free memory chain to find something. This takes time. To allocate something off of the stack, you just increase the stack pointer.
If you do benchmarks, you'll find that this (At least, you would have last I checked, which was with an old DOS compiler):
Foobar f1(1,2,3);
is dramatically faster than this:
Foobar* f1 = new Foobar(1,2,3);
for the reasons mentioned above.
This is because the former looks something like this in psuedocode:
f1 = StackPtr
StackPtr += sizeof(Foobar)
f1.Constructor(1,2,3)
while the latter generates something like:
Start at beginning of free block chain
for each block
is it big enough?
if so, is it too big?
if so, split it and return beginning
otherwise return it
f1 = returned block
f1.Constructor(1,2,3)
Where this really gets compelling is if you a class has member classes which have member classes, if those members are all allocated, you end up with lots of little chunks of memory. On the other hand, if they are all regular members, and not pointers to things that are allocated, they just become part of the parent object's size.
If you have this:
class A
{
class B {} b;
class C {} c;
};
then this line gets memory from the stack merely by incrementing the stack pointer by sizeof(A):
A a;
This is basically one assembly op which, unless there is a page fault, is nothing, timewise. On the other hand, this:
class A
{
class B {} *b = new B;
class C {} *c = new C;
};
Created like this:
A *a = new A;
Requires three searchs through the heap to find memory. Not only will this take more time, but this is more likely to generate a page fault, both because you might not find contiguous memory, but also because each heap object has overhead associated with it (the list of free and used memory blocks) while each stack object usually does not.
(The other reason to prefer the former sort of class is that even if you decide to use the heap for the owning class, you use a bigger chunk, allocating only once for the class rather than for each memory object.)
It doesn't.
Which is why the compiler (or in the alloca() case, the programmer) has to be smart enough to know not to return a reference (or assign it to a global, etc.).
I was disappointed with that whole category. It seemed more of a "Who is your favorite famous person who occasionally shows up on Slashdot?".
Would you also send your pointers across a network and expect them to work at the other end?
The idiots who wrote the code that caused me the pain would have...
This involves one of the internal debates I've had about C for years. C allows you to shoot yourself in the foot. That is all well and good as I (I hope) know what I'm doing. The trouble is that, with turnover in this industry what it is, a new foot might have arrived by the time the bullet hits. (Unfortunately, I've often been the new foot.)
One huge advantage C++ has here is that you can declare on object on the stack. This makes your fourth bullet go away and turns the second bullet into something like two asm instructions.
(And, of course, there is no bytecode to load, so the first bullet becomes merely "call the constructor", whether the stack or the heap is used.)
Even in C++, the heap is overused. With moderately careful design, the majority of objects can be left on the stack. I'm convinced that one of the reasons that people think C++ is so much slower than C is that many C++ programmers don't think about this enough.
Calls the hierachy of constructors of all Foos superclasses. Quite slow.
What strikes me here is that part of the problem is these huge object hierarchies that people seem to love so much. A very flat hierarchy reduces this quite a bit.
Or maybe it only bothers to do this when resources get tight. Perhaps another malloc comes along wanting the same size (roughly) as the thing just freed. We just give it the recently freed chunk. We then don't have to build a new one.
Caveat: I have no idea if this makes sense, performance-wise, in the real world.
If you kept the entire compiled code around (and not just part of it), you could keep profiling info, and only attempt further optimization the Nth time a block was run in a certain period, were N is some sufficiently high number. You could also be really smart and save the compiled code so that next time you execute, you don't need to recompile everything.
Imagine a program that speeds up the more times you run it...
Perhaps you could set some sort of "optimization threshold", which limits the percentage of time the system tries to improve over time. The first time you run, there is the complete overhead of compiling. The second and subsequent times, a 10% slowdown for optimization. After a few runs, with the data collected, the performance improvement beats the 10% overhead and you are better off.
I think that what he is saying is that sometimes you could gain a lot of speed in java by allocating on the stack. This has been one of my biggest problems with Java, the way everything is done in the heap, not the stack. If an object is only used in one function, (or functions it calls) it makes perfect sense to put it on the stack, not the heap.
/*dostuff*/
/* Compiles roughly to Bar=sp, sp+=y (or is it sp-=y?)*/
/*dostuff*/
/*No free needed, popped off of stack.*/
(I'd post an example, but I'm not a Java guy, and don't want to screw up my syntax in public.)
I used to do something like this in C, manually. Suppose you have this:
void Foo(int y)
{
char *Bar=malloc(y);
free(Bar);
}
With some compilers, you can save time and avoid memory leaks by allocating on the stack like this:
void Foo(int y)
{
char *Bar=alloca(y);
}
I'd think that if a Java optimizer were smart enough to know when to do this, it'd speed things up tremendously for some programs.
The trouble is that you can't always use sizeof() and you can't always change your types around. The classic case (which I ran into, painfully) is when you have two different machines with two different architectures passing structures around.
It is easy enough to define a structure like this:
struct
{
int Foo1;
int Foo2;
};
and yes, regardless of the machine, this will compile and run most anywhere, assuming that Foo1 and Foo2 are never larger than 2^15. The trouble is, if you are using that structure two places, one on an 8-bit machine, another on a system that is being upgraded from a 16-bit OS to a 32 bit OS, well, you have pain. (An unfortunately all too real situation I got stuck with.)
Now in my situation, you can certainly say that the idiot authors should have used shorts (and they should have), but even then, there is no guarantee that a short will be the same size in both places. I foresee a lot of pain when sizeof(long) stops equalling sizeof(int) as we move to 64 bits.
So what you end up doing is having the structure defined twice, potentially differently, for each side of the pipe. Not fun to maintain.
(And don't get me started on packing.)
Here's something to really wierd yourself out thinking about:
Suppose you were able to create a perfect working replica of your brain. (Perhaps electronic, but functionally the same, including timings.) Now suppose you take this new working replica, download the "software", cut it in half, cut your brain in half, and create two half electronic/half gray matter brains.
Which is you?
Jeez, you'd think the copy would be happy. The copy gets the cool new immortal body while you're stuck with the crappy old one.
(Just a flip comment. I'm sure the book is good.)
95% of my CD listening is at a PC. If I can't use the CD in a CD-ROM, it is just a useless hunk of plastic, little better than an AOL disk.
I'd say this calls for a boycott, but why bother? They're products are useless. Obviously, no one is going to buy a useless product.
And looking around the office, and seeing the number of headphones hooked into computers, I'd say that they've grossly underestimated the impact of this. And we're not talking about just techies, either.
Anyone got an e-mail for BMG so that I can inform them that they are starting to produce products that are useless to me?
I think that was a very subtle joke. Just check out the post of the AC that replied.
Hint: I think that even profits of 5,000,000,000% more than they are making now are possible.