His analogy of the USPTO as a loose woman...
on
Paul Graham on Patents
·
· Score: 3, Funny
It's a very good article -- and while I've not yet finished reading it, I loved this quote;
"...the USPTO in effect slept with Amazon on the first date."
As a side note, if any USPTO examiners who are assigned to one of the several applications I have pending are reading this; I will still respect you in the morning -- no really, I will.:-)
Of course you two are absolutely correct. I had a particularly bad brain-fart moment there. The original post claiming that an imax frame was about the size of a business card is pretty darn close. I just had some hare-brained idea that it was much bigger, and while I dredged up the frame dimension in mm from memory, didn't actually engage my brain for a sanity check comparison against what I thought I knew about an imax frame size relative to a paperback.
My bad. (that'll teach me to post without reading it and engaging more than a couple of neurons in the process.)
It's much bigger than a business card -- its just under 50mm high, and as wide as they want. (That's because imax runs 70mm film horizontally through the camera/projector. From that 70mm, you take off the sproket holes and sound tracks, and that leaves you with about 50mm...)
So each imax frame is slightly larger than a standard paperback novel. ie. freakin *huge*.
It's been a while since I worked there, but I think that IBMers are very used to working for people who are not nearly as smart as they are. To IBMers, this is probably just another data-point to confrim the old interpretation of the acronym IBM == Idiots Become Managers.
There's a third option which you are not considering -- that the terrorists are competent, but the intelligence and counter terrorist agencies are more efficient than you believe -- Or it could (more likely) be some mix of all three.
Your posts have the ring of "truthiness" to them, however, you give yourself away with the phrase "relatively poorer" -- in absolute terms in inflation adjusted dollars, the poor are not poorer than they were decades ago. Where they are *relative* to everyone else does not matter for this particular argument (one can argue that it is unjust etc, but that is a seperate discussion) -- when you say the poor are poorer than they were decades ago, you imply that they have less spending power in absolute terms. And this is clearly not so. Your post above indicates that you are well aquainted with these facts, so that leaves me with the conclusion that you are actively attempting to decieve in order to promote some agenda.
Firstly I am not American (I'm Canadian), and secondly I have no illusions about ethanol as a fuel for vehicles. It's costly to manufacture, burns fossil fuels in the process of producing it, and in the end has a substantially lower energy density than gasoline -- an important consideration for a vehicular fuel -- as you have to cart the damn stuff around in the vehicle along with it's containment system (listen up you hydrogen and LNG proponents) -- and each extra kg there reduces your fuel efficiency.
Each SPU can do 2 DP FMACs (in one vector) in 6 cycles -- not pipelined. and at 3.2 GHz. Then you can add the single pipelined DP FMAC unit in the PPE.
Sure, it's an order of magnitude less than SP, but it's not that anemic. And if I weren't still under NDA, I could speculate about what IBM/SONY might be doing about that situation. But I wont.
Oh and back on topic, I used to work at IBM on compilers, and I recognized some of the names on the list of authors of the Octopiler paper -- and those are some *seriously* smart dudes who really know what they're doing when it comes to compilers. If anyone can pull it off, they can.
I generally do one thing at a time, do it as well as I can, and finish it -- then handle all the little things that piled up, then move on to the next thing.
It does mean that it might be a couple of days until I answer your email, but I get things accomplished, and deliver working software on a regular basis.
Continually thrashing around, switching from one task to another, is a very unproductive way to work -- at least for me -- I find getting "into the zone" takes at least 1/2 an hour. And sometimes doesn't really start flowing until one or two hours of really carefully contemplating the problem at hand.
But different people have different styles of working -- a good manager will figure out what works for who and do his best to make sure each has an environment that is productive for that individual.
This will be similar to Apple buying Next. In the end, all the senior people of Next wound up running Apple -- Apple adopted NextStep as their OS, and called it OSX.
With any luck, Jobs, Lasseter, and other senior Pixar people will wind up running Disney. It would be a substantial improvement.
As someone who has a few patents to his name and several more pending, I can say that if the invention your patent describes is unreproducable to you or anyone else skilled in the relevent field, it is a very bad patent, and it's *your* fault -- not the lawyers.
Sure, it sounds to me like you have a crap patent lawyer, but it's your job to push back and revise it so it does make sense and so it accurately describes your invention.
Even with a good lawyer who really understands your invention, this can take several iterations.
For you slashdotters out there who are looking for a good patent firm, Two that I've worked with and I thought were very good are Stearne, Kessler, Goldstein & Fox (www.skgf.com), and Staas & Halsey (www.stassandhalsey.com).
While it's been a few years, I particularly enjoyed working with Mike Ray of SKGF -- he's very sharp, and really good at explaining *why* things are written the way they are in your patent.
Re:.NET performance
on
Pro C#
·
· Score: 2, Interesting
Mr A.C.
I have seen similar results with a 3D Perlin noise generator -- I was comparing Intel vs MS, vs hand coded SSE assembler. For pure entertainment I tried a -clr build and it was quite alot slower. Another interesting point was that the newer compilers (both Intel and MS) generated code that was close to or better than the SSE assembler implementation.
I remember clearly hearing Bill mutter under his breath while wandering the halls of Alias; "I hate computers -- I [expletive deleted] HATE computers -- but I *especially* hate Windows computers!"
(This was`a number of years ago.)
Bill was always great to work with -- I hope Microsoft treats him well, and I wish him the best.
The real unsavory reason they're building below ground is that they expect things above ground to be blowing up. Hardly reassuring to potential customers.
Sony is screwed in court -- how can they argue they're innocent, and that this wasn't a deliberate act of sabotage when their own CEO (Howard Stringer) said in 2001;
"Right now it would be possible for us, and I've often thought it would cheer me up to do it, you could dispatch a virus to anybody whose files contain us or Columbia records..."
At Alias, we use Agile and Scrum very extensively. The Sketchbook team was among the first at Alias to adopt it at our company -- Jim Highsmith even gave us a little write up in one of his books.
We don't, however, do that much pair programming. And the whole completely open office space works for some, and definitely not for others. For myself, I'm way too easily distracted -- so I need a nice quiet and private cubicle in order to achieve the state of "flow" where I can write code. In my experience, pair programming works for debugging and integrating code -- and not so well for creating it. YMMV.
Sketchbook has come in on time and on budget, and with extremely high quality. Agile and Scrum had something to do with it. I think the fact that we had a clear vision, a small and very experienced team, a really good working relationship with our usability team and research team, great QA, and excellent management had at least as much to do with it.
As a process, its the only one I've seen in 20 years of doing this that actually makes the life of a programmer better, not worse.
loop_: // you can unroll this loop... movdqa xmm0, [ebx] // aligned-- use movdqu for unaligned paddd xmm1, xmm0 add ebx, 16 dec ecx jnz loop_
// now just need to do a horizontal add... // but there is no horizontal integer add instr, so... movdqa xmm0, xmm1 0123 pshufd xmm0, xmm0, 1// xmm0 >>= 64 shift instr can only do max of 16 paddd xmm0, xmm1 movdqa xmm1, xmm0 pshufd xmm0, xmm0, 2// xmm0 >>= 32 paddd xmm0, xmm1
// result is in the last dword of xmm1 movd result, xmm0
// I'm pretty sure those shuffle constants are correct...
That is correct -- Modern processors perform divides by having a reciprocal estimate lookup table. This table produces an estimate with 12 or so good bits of precision. Iterative refinement (typically microcoded) then produces the rest of the bits. After that the reciprocal is multiplied in, and you get the result.
More recently this has been somewhat exposed, as most all modern processors have a reciprocal estimate instruction which executed in a single cycle. This is very useful if, for example, you want to normalize a bunch of normal vectors before passing them into the graphics pipeline. 12 bits is almost always enough for this purpose, and the reciprocal sqrt instruction is very much your friend here. So something that was dominated by the ~60 cycles of 1.0f/sqrt(sum_of_squares) becomes 1 cycle. Total speedup is about 10x -- and it's vectorizable -- the SSE unit will do a vector rsqrte.
My understanding of the pentium fdiv bug is that a section of the reciprocal estimate table had bad data in it.
This, in my opinion, counts as software, as would the microcode. If the bug had been in the multiplier, adder, or logic circuitry of the lookup table, then it would count as hardware.
Many, if not all the complex ciscy instructions are implemented in microcode -- so I believe that a bug in them would count as a software bug.
Slashdot Mirror
It's a very good article -- and while I've not yet finished reading it, I loved this quote;
:-)
"...the USPTO in effect slept with Amazon on the first date."
As a side note, if any USPTO examiners who are assigned to one of the several applications I have pending are reading this; I will still respect you in the morning -- no really, I will.
Of course you two are absolutely correct. I had a particularly bad brain-fart moment there. The original post claiming that an imax frame was about the size of a business card is pretty darn close. I just had some hare-brained idea that it was much bigger, and while I dredged up the frame dimension in mm from memory, didn't actually engage my brain for a sanity check comparison against what I thought I knew about an imax frame size relative to a paperback.
My bad.
(that'll teach me to post without reading it and engaging more than a couple of neurons in the process.)
It's much bigger than a business card -- its just under 50mm high, and as wide as they want. (That's because imax runs 70mm film horizontally through the camera/projector. From that 70mm, you take off the sproket holes and sound tracks, and that leaves you with about 50mm...)
So each imax frame is slightly larger than a standard paperback novel. ie. freakin *huge*.
Both of the posts above are excellent advice, but particularly the first.
It's been a while since I worked there, but I think that IBMers are very used to working for people who are not nearly as smart as they are. To IBMers, this is probably just another data-point to confrim the old interpretation of the acronym IBM == Idiots Become Managers.
There's a third option which you are not considering -- that the terrorists are competent, but the intelligence and counter terrorist agencies are more efficient than you believe -- Or it could (more likely) be some mix of all three.
Your posts have the ring of "truthiness" to them, however, you give yourself away with the phrase "relatively poorer" -- in absolute terms in inflation adjusted dollars, the poor are not poorer than they were decades ago. Where they are *relative* to everyone else does not matter for this particular argument (one can argue that it is unjust etc, but that is a seperate discussion) -- when you say the poor are poorer than they were decades ago, you imply that they have less spending power in absolute terms. And this is clearly not so. Your post above indicates that you are well aquainted with these facts, so that leaves me with the conclusion that you are actively attempting to decieve in order to promote some agenda.
You're wrong on two counts.
Firstly I am not American (I'm Canadian), and secondly I have no illusions about ethanol as a fuel for vehicles. It's costly to manufacture, burns fossil fuels in the process of producing it, and in the end has a substantially lower energy density than gasoline -- an important consideration for a vehicular fuel -- as you have to cart the damn stuff around in the vehicle along with it's containment system (listen up you hydrogen and LNG proponents) -- and each extra kg there reduces your fuel efficiency.
Wouldn't it be more efficient to run the vodka straight into the fuel tanks instead of through a bunch of swedes?
:-)
(sorry for the flame bait
(BTW congrats on the gold in mens hocky -- your team deserved it -- they played magnificently)
Not quite as bad as you make it out to be --
Each SPU can do 2 DP FMACs (in one vector) in 6 cycles -- not pipelined. and at 3.2 GHz. Then you can add the single pipelined DP FMAC unit in the PPE.
Sure, it's an order of magnitude less than SP, but it's not that anemic. And if I weren't still under NDA, I could speculate about what IBM/SONY might be doing about that situation. But I wont.
Oh and back on topic, I used to work at IBM on compilers, and I recognized some of the names on the list of authors of the Octopiler paper -- and those are some *seriously* smart dudes who really know what they're doing when it comes to compilers. If anyone can pull it off, they can.
I generally do one thing at a time, do it as well as I can, and finish it -- then handle all the little things that piled up, then move on to the next thing. It does mean that it might be a couple of days until I answer your email, but I get things accomplished, and deliver working software on a regular basis. Continually thrashing around, switching from one task to another, is a very unproductive way to work -- at least for me -- I find getting "into the zone" takes at least 1/2 an hour. And sometimes doesn't really start flowing until one or two hours of really carefully contemplating the problem at hand. But different people have different styles of working -- a good manager will figure out what works for who and do his best to make sure each has an environment that is productive for that individual.
This will be similar to Apple buying Next. In the end, all the senior people of Next wound up running Apple -- Apple adopted NextStep as their OS, and called it OSX.
With any luck, Jobs, Lasseter, and other senior Pixar people will wind up running Disney. It would be a substantial improvement.
As someone who has a few patents to his name and several more pending, I can say that if the invention your patent describes is unreproducable to you or anyone else skilled in the relevent field, it is a very bad patent, and it's *your* fault -- not the lawyers.
Sure, it sounds to me like you have a crap patent lawyer, but it's your job to push back and revise it so it does make sense and so it accurately describes your invention.
Even with a good lawyer who really understands your invention, this can take several iterations.
For you slashdotters out there who are looking for a good patent firm, Two that I've worked with and I thought were very good are Stearne, Kessler, Goldstein & Fox (www.skgf.com), and Staas & Halsey (www.stassandhalsey.com).
While it's been a few years, I particularly enjoyed working with Mike Ray of SKGF -- he's very sharp, and really good at explaining *why* things are written the way they are in your patent.
Mr A.C.
e rlin.htm )
I have seen similar results with a 3D Perlin noise generator -- I was comparing Intel vs MS, vs hand coded SSE assembler. For pure entertainment I tried a -clr build and it was quite alot slower. Another interesting point was that the newer compilers (both Intel and MS) generated code that was close to or better than the SSE assembler implementation.
(For those wondering what Perlin noise is and what it's good for, check out http://freespace.virgin.net/hugo.elias/models/m_p
I remember clearly hearing Bill mutter under his breath while wandering the halls of Alias; "I hate computers -- I [expletive deleted] HATE computers -- but I *especially* hate Windows computers!"
(This was`a number of years ago.)
Bill was always great to work with -- I hope Microsoft treats him well, and I wish him the best.
The real unsavory reason they're building below ground is that they expect things above ground to be blowing up. Hardly reassuring to potential customers.
They are not leveraging spaceship one -- they are using it.
Don't use the word leverage unless you can give an estimate in newton meters. Doing otherwise makes you sound like a PHB.
They're
obviously
being
paid
by
the
line.
Printed on a pink page of paper;
To: $yourEmployersName
I regret to inform you that as of $date your services as an employer are no longer required.
Regards,
$yourName
he's right. (and I have no mod points)
Sony is screwed in court -- how can they argue they're innocent, and that this wasn't a deliberate act of sabotage when their own CEO (Howard Stringer) said in 2001;
"Right now it would be possible for us, and I've often thought it would cheer me up to do it, you could dispatch a virus to anybody whose files contain us or Columbia records..."
Sorry -- it's right there on the citizenship test -- Who scored the winning goal in the 1972 Canada cup series between Canada and the Soviet Union?
If you can't answer correctly, they will deport you the same day.
At Alias, we use Agile and Scrum very extensively. The Sketchbook team was among the first at Alias to adopt it at our company -- Jim Highsmith even gave us a little write up in one of his books.
We don't, however, do that much pair programming. And the whole completely open office space works for some, and definitely not for others. For myself, I'm way too easily distracted -- so I need a nice quiet and private cubicle in order to achieve the state of "flow" where I can write code. In my experience, pair programming works for debugging and integrating code -- and not so well for creating it. YMMV.
Sketchbook has come in on time and on budget, and with extremely high quality. Agile and Scrum had something to do with it. I think the fact that we had a clear vision, a small and very experienced team, a really good working relationship with our usability team and research team, great QA, and excellent management had at least as much to do with it.
As a process, its the only one I've seen in 20 years of doing this that actually makes the life of a programmer better, not worse.
Try;
// you can unroll this loop... // aligned-- use movdqu for unaligned
// now just need to do a horizontal add...
// but there is no horizontal integer add instr, so... // xmm0 >>= 64 shift instr can only do max of 16 // xmm0 >>= 32
// result is in the last dword of xmm1
// I'm pretty sure those shuffle constants are correct...
mov ecx, b
shr ecx, 2
pxor xmm1, xmm1;
loop_:
movdqa xmm0, [ebx]
paddd xmm1, xmm0
add ebx, 16
dec ecx
jnz loop_
movdqa xmm0, xmm1 0123
pshufd xmm0, xmm0, 1
paddd xmm0, xmm1
movdqa xmm1, xmm0
pshufd xmm0, xmm0, 2
paddd xmm0, xmm1
movd result, xmm0
That is correct -- Modern processors perform divides by having a reciprocal estimate lookup table.
This table produces an estimate with 12 or so good bits of precision. Iterative refinement (typically microcoded) then produces the rest of the bits. After that the reciprocal is multiplied in, and you get the result.
More recently this has been somewhat exposed, as most all modern processors have a reciprocal estimate instruction which executed in a single cycle. This is very useful if, for example, you want to normalize a bunch of normal vectors before passing them into the graphics pipeline. 12 bits is almost always enough for this purpose, and the reciprocal sqrt instruction is very much your friend here. So something that was dominated by the ~60 cycles of 1.0f/sqrt(sum_of_squares) becomes 1 cycle. Total speedup is about 10x -- and it's vectorizable -- the SSE unit will do a vector rsqrte.
My understanding of the pentium fdiv bug is that a section of the reciprocal estimate table had bad data in it.
This, in my opinion, counts as software, as would the microcode. If the bug had been in the multiplier, adder, or logic circuitry of the lookup table, then it would count as hardware.
Many, if not all the complex ciscy instructions are implemented in microcode -- so I believe that a bug in them would count as a software bug.