Revelation:

I understand that you'll not be producing a 32bit OENGINE after all, and that JRev will be your 32bit solution.

I'm trying derive a concise sentence that describes how JRev is implemented. JRev, as I understand it, is a sort of browser/JVM extension that would allow a JVM to interpret RBASIC ? is that correct?

Also, can you provide any benchmarks comparing the speed of RBASIC running in a JVM vs the same code running under 16bit OENGINE?

There's a lot of $$ and effort involved with updating our customers to another major version of OI. I'll need some hard data to show that there will be a real increase in performance.

Thanks,

Andy

Andy,

I'm trying derive a concise sentence that describes how JRev is implemented.

Revelation Software does not use this discussion forum for official announcements and strategic direction discussions. This is my personal response to your set of questions.

jRev is the project name for the R&D of our Java-based database application development tools. The deliverables of this project will almost certainly include a server-based Java implementation of the linear hash database filing system (similar to the NLM and NT Service) and an integrated development environment (IDE) in a role similar to the OI and ViP products today. Your questions are directed primarily to the IDE.

JRev, as I understand it, is a sort of browser/JVM extension that would allow a JVM to interpret RBASIC ? is that correct?

Regarding the IDE, that is not correct, but you are in the right ball-park. Our primary goal was to fit in with the existing/proposed technical standards, and Revelation's object code is not a standard. Additionally, interpreting BASIC+ in Java, even if the JVM is based on a dynamic compiler or a JIT, is far from optimal from a resources point of view. Lastly, we would be re-inventing the wheel, so to speak, if we built a language execution system (BASIC+) in a language execution system (JVM).

However, we realize the value of BASIC+ to our customers, and we would like to keep those customers so we will keep BASIC+. Given this, the above issues, and some other technical issues regarding Java, there was only one good choice: BASIC+ must compile to the same standard structure (known as the "Java .class structure") as Java source is compiled to. (The implementation of this is called "pluggable scripting" and is an integral part of the jRev component model, which produces Javabean classes.)

Also, can you provide any benchmarks comparing the speed of RBASIC running in a JVM vs the same code running under 16bit OENGINE?

At this point, no. Our Java benchmarking in general is all over the board, depending on the JVM implementation and the task at hand. (As an example, we had jLH benchmarks with the MS JVM that were faster than Arev … that is unbelievable considering Arev is hand-coded assembly.)

There's a lot of $$ and effort involved with updating our customers to another major version of OI. I'll need some hard data to show that there will be a real increase in performance.

Our reasons for the jRev R&D include providing a much more scalable architecture for developing applications with and providing these technologies to our customers and their applications. jRev technologies may also provide increased performance due to the component architecture (which produces executable classes) and to the immense amount of work being done in the JVM arena by other industry players with static (e.g. Supercede), dynamic (e.g. Hotspot), and JIT (e.g. MS JVM) compilers.

Cameron Purdy

Revelation Software

] we had jLH benchmarks with the MS JVM that were faster

] than Arev … that is unbelievable considering Arev is

] hand-coded assembly.

On the same machine?

Andy,

On the same machine?

Yes. (You were kidding, right?)

Cameron Purdy

[email protected]

Cameron,

] (You were kidding, right?)

No, I'm just scratching my head. I'm wondering how an Rbasic program, compiled to Java byte code, running in a JVM, and running inside Windows could be faster than the same Rbasic program running on the same machine in hand-coded assembly under DOS.

I must be missing something, because in my experience,

1) I've never seen a case where extra levels of indirection actually improve raw performance, and

2) I've seen AREV/DOS on a 333 MHz machine, and it simply screams. I'd wager that ANY Windows-based database running on the same machine, regardless of the execution model, would suffer in the comparison.

That's why I asked about the platform.

Anyway, thanks for the detailed response to my original post.

-Andy

Andy,

No, I'm just scratching my head. I'm wondering how an Rbasic program, compiled to Java byte code, running in a JVM, and running inside Windows could be faster than the same Rbasic program running on the same machine in hand-coded assembly under DOS.

The performance test was of LH file access (reads/writes/etc.) and was not intended to test BASIC+ operations.

Secondly, the Java code was not being interpreted; using a technology known as JIT (Just In Time) compilation, Microsoft's implementation of the JVM converts Java .class structures into 32-bit x86 executable code on the fly. There are other JIT implementations, including from Sun, Borland and Symantec for x86 and various vendors for other platforms. Additionally, there are JVMs implemented as static compilers (from Supercede and Fujitsu) that can produce EXE and DLL files from Java .class structures. There is also a knew breed of JVMs which use "dynamic" compilers that compile on the fly as the program is running, using run-time profiling for optimizations, so the program gets faster as it runs.

I don't want to mislead you, though. We are not using Java for performance reasons and, depending on the task at hand and the JVM implementation, it may often be slower. We are using Java because we believe it offers the technologies we need to provide the development tools and other functionality that developers (our customers) need to build great applications.

Cameron Purdy

[email protected]

Cameron,

Ok, I think I've got the answers to my original questions:

o jRev allows applications developed with Revelation tools to enjoy many of the benefits of java by compiling RBASIC to java class structures, and by providing a server side java based LH server.

o There are no benchmarks available, but in general, RBASIC code running in a typical browser is not expected to be as fast as the same RBASIC code executed by the current 16 bit OENGINE.

o As with any java application, you could get better performance by compiling the java class structures jRev generates for your RBASIC

app into a stand-alone, platform-specific application. Another possiblity is to upgrade your clients systems to use one of the newer, specialized JVMs that dynamically compile your app as it runs.

BTW, I appreciate the level of detail in your responses to my posts. I finally feel I'm getting a handle on what jRev is.

Thanks,

Andy

View this thread on the forum...