Re: Oracle #1? Then why are these still missing...

Thomas Kyte wrote:

>A copy of this was sent to gary_at_onegoodidea.com (Gary O'Keefe)
>(if that email address didn't require changing)
>On Thu, 29 Jul 1999 09:24:07 GMT, you wrote:

[ code examples and stuff snipped ]

>>Not to put you down Thomas, but these are horrible. On any modern
>
>gee, i found them to be useful -- and fast enough.

Only because the data set you used for your test harness is so small.

>>processor (i.e. designed after the invention of the transistor) AND,
>>OR, or XOR take 1 clock cycle to execute. Here with OR and XOR you
>>have the overhead of pushing the function params onto the stack,
>>jumping to the function's address space, popping the values off the
>>stack, assigning the memory to 5 variables (one implicitly),
>>assignments, loops, conditional branches, pushing the return value
>>back onto the stack and clearing up after the function has finished.
>>God alone knows how long this will take to execute. You have managed
>>to replace a 1 clock cycle instruction with one that will take >1000,
>>3 orders of magnitude longer than it would take if implemented
>>natively. This is not an achievement.
 

>plsql is an interpreted language remember, it is a step above scripting but it
>*is not a compiled into object code binary language*. I would assume you would
>have to hate plsql because its not compiled directly into object code (it may be
>some day but it certainly isn't now).

I don't hate PL/SQL, I just find it limited. I understand it's a solution designed for the problem space it inhabits, and when that space was defined these sorts of operation were considered only marginally useful to the vast majority of developers. But when you need them, you really need them. Bitwise operations can be mapped in the interpreter directly to processor bytecode.

>even if bitor/bitxor was done internally -- it would take the overhead of
>pushing the function params onto the stack, jumping, popping, assigning, etc,
>etc, etc. "=" in plsql is a function call. "<" is a function call. AND is a
>function call -- they all are. Every thing you just listed above is true of any
>plsql function.

And I'll bet dollars to doughnuts that the interpreter maps the integer and fp operations straight to bytecode in the function body.

>>Argghhh! I just noticed that you call bitand twice per loop. What is
>
>lets see you do it *without* calling bitand 2 times -- its sort of important (it
>won't work unless you do). Also, in the first one (bitor) bitand is only called
>2 times if the first call and compare is FALSE.
>
>If i didn't call bitand 2 times -- then you could say "argghhh", your algorithm
>is botched. I actually spent a bit of time trying many different
>implementations to discover this to be the fastest I could code.
>
>>this - Voyage to the Bottom of the Performance? What is the point in
>
>No. If you call bitor, bitxor a couple of dozen times

And what happens if you have to call it a couple of thousand times? Or a couple of million times? Anyway, no doubt bitand is implemented atomically in the interpreter and was a bad example.

>>buying a dog and barking yourself? The ALU is an integral component of
>>the processor - use it! I appreciate the effort in implementing these
>>algorithms, but it is misguided to attempt these sorts of operations
>>in PL/SQL.
>>
>
>Lets see -- plsql doesn't have bitor. I find a need to do bitor. I write a
>bitor. Misguided me I guess -- I just gave myself the ability to do something I
>needed to do (and presumably will have to do one way or another) and previously
>could not.

You are missing the point. These are the sort of atomic operations that can be quickly and robustly added to the interface. Their omission was a serious oversight, but can be corrected in (at the most) a couple of programmer-days. To people who need to perform this sort of calculation the performance increase would be incredible. It's not just business-weenies that use Oracle products (although they are the ones that pay for them ;), technical people need to be able to address the problem space they are presented with in terms they understand, and if the interface requires them to have to go round the houses for a solution to what they perceive to be a glaring, but frustratingly easy to correct, omission then confidence in the product will fall.

It just means that I have to spend more time re-inventing the wheel and less time on Usenet engaged in stimulating corresponence with you. And you have to spend more time dealing with the problems of folk like me.

>I could take the above code and implement it in java, I could take it an
>implement it in C. I found the above to be
>
>- the most portable (everyone with 7.1 and up can use it)
>
>- the easiest to understand and install (this is pretty important to me as I'd
>get thousands of emails with questions and installation issues for anything more
>complex)

As someone who has to deal with end-users too, I can say this with confidence: I know your pain.

>- works *fast enough* for most things.
>
>True -- its not as fast as C (i can say that in general about plsql) but it
>works, it does the job, and it is only one of at least 3 ways I know how to do
>this, each with various performance and implementation implications.

I'm not disputing that there are alternatives. What I'm saying is that we shouldn't have to go looking for alternatives for *bitwise* operations - let's limit ourselves to this particular issue. They are part of the functionality of the hardware, and that functionality should be exploited.

Gary

--
Gary O'Keefe
gary_at_onegoodidea.com

You know the score - my current employer has nothing to do with what I post