Lets start ... Access to the virtual machine

[marten]

Ok, a new support forum ... hope, that this will help this nice product in the future.

My question to the company is pretty simple:

Has instantiations unrestricted access to the virtual machine (source) on all platforms of this product - and will be therefore able to deliver the product (whatever hardware is coming) in the future (without IBM).
The question may seem to be strange, but I always compare the VA7 outsource with the way OS/2 is handled. Another company is now selling OS/2 under the name eCS - and they do quite a good work, but they have one problem: they have no access to the OS/2 kernel.

Another question (which will be denied I think): are there any ideas to give the customer access to the virtual machine code (as Cincom does it now) ?

And then my third question: Strongtalk has been published and I would like to know, if there are any ideas to improve the speed of VA using Strongtalk ???

[Eric Clayberg]

Has instantiations unrestricted access to the virtual machine (source) on all platforms of this product - and will be therefore able to deliver the product (whatever hardware is coming) in the future (without IBM).

Yes and Yes.

The question may seem to be strange, but I always compare the VA7 outsource with the way OS/2 is handled. Another company is now selling OS/2 under the name eCS - and they do quite a good work, but they have one problem: they have no access to the OS/2 kernel.

We have access to everything VAST related including all of the source for VAST, the VM, and ENVY.

Another question (which will be denied I think): are there any ideas to give the customer access to the virtual machine code (as Cincom does it now) ?

No. There are no plans to do that. We have full access to the VM source for any purpose that we need (such as creating new VMs for new platforms), but we are not permitted to give that source to anyone else without IBM's permission. Ultimately, IBM still owns the IP, and the VM source is still considered to be highly proprietary (IBM uses it for things other than Smalltalk).

We have, in effect, a permanent, exclusive license to the VAST IP that allows us to modify, market, sell and support the VAST product for as long as we want. We can't, however, transfer our license to someone else (without IBM's permission) or release certain sources deemed proprietary to IBM (like the VM).

And then my third question: Strongtalk has been published and I would like to know, if there are any ideas to improve the speed of VA using Strongtalk?

That, of course, assumes that the speed of VAST would be improved by using Strongtalk. It also assumes that the incremental speed improvement that might be gained would offset the potential for disastrous incompatibilities with the existing body of VAST code (ours and customers).

We haven't had anyone complain about the speed of VAST (most folks have told us it is faster than Java and requires far less memory). Do you think that the speed of VAST is really an issue?

We certainly read the Strongtalk announcement with great interest. How or if we might apply it to VAST is still an open question. Nothing in our deal with IBM would prevent us from using all or part of it (or swapping out the existing VM entirely). Actually doing something like that would be a huge decision and not something we would do lightly. The risk would be tremendous as would be the cost. The ultimate payoff (in terms of any significant performance improvement or an improvement in our ability to sell the product) is also unknown.

[Hans-Martin]

There are some things which would benefit from understanding how the VM works, even if source code can not be made available:
- to fix some bugs in a component from a company which does not exist anymore, I needed to decompile their code so I could change it. This took quite a bit of effort since the VAST bytecodes are not documented.
- I tried to implement continuations using the primitives for process creation and forking. In the end, I had to give up since the VM crashed all the time...

These things are much easier in implementations such as VW where the conceptual execution model is visible to the user, even if their actual implementation is hidden.

Cheers,
Hans-Martin

[Eric Clayberg]

This took quite a bit of effort since the VAST bytecodes are not documented.

The bytecode mappings can be found in the EsParsing class>>#_PRAGMA_BytecodeValues method.

The full source of the VAST compiler and parser is also available in the system, so you can see how the bytecode is generated and which bytecodes are used in which circumstances.

We have pulled together some of this information on the VA Smalltalk Bytecode page.

[marten]

That, of course, assumes that the speed of VAST would be improved by using Strongtalk. It also assumes that the incremental speed improvement that might be gained would offset the potential for disastrous incompatibilities with the existing body of VAST code (ours and customers).

We haven't had anyone complain about the speed of VAST (most folks have told us it is faster than Java and requires far less memory). Do you think that the speed of VAST is really an issue?

Just to throw some oil into the fire . I tried some Strongtalk benchmarks (every benchmark is lying ... I know) on three platforms:

Strongtalk: 80 ms
VisualWorks: 650 ms
VisualAge: 1450 ms

I think, the system is worth looking ...

Marten

Code: Select all

Object subclass: #StrgTest
    instanceVariableNames: ''
    classVariableNames: ''
    poolDictionaries: ''!

!StrgTest class publicMethods !

benchmark: blk

   | best |
   best := 3200000000000000000000000000.
   10 timesRepeat: [
      | time  |
      time := Time millisecondsToRun: blk .
      Transcript show: time printString; space.
      best := time min: best.   ].
   Transcript show: ' Best Time = '; show: best asString; cr.
   ^best!

evaluateBlock: blk

   ^blk value!

fancyStoreIntoArray: a

   ^self evaluateBlock: [ a at: 1 put: 3 ]!

notSoSimpleTest: n
   "StrgTest benchmark: [ StrgTest notSoSimpleTest: 100000000 ]"

   | a |
   a := Array new: 1.
   n timesRepeat:
      [ self fancyStoreIntoArray: a  ]! !

StrgTest initializeAfterLoad!


[daswartz]

That, of course, assumes that the speed of VAST would be improved by using Strongtalk. It also assumes that the incremental speed improvement that might be gained would offset the potential for disastrous incompatibilities with the existing body of VAST code (ours and customers).

We haven't had anyone complain about the speed of VAST (most folks have told us it is faster than Java and requires far less memory). Do you think that the speed of VAST is really an issue?

Well... I didn't know complaining would do any good.

Generally, VAST is adequately efficient. Yet, the applications we build often have some pretty long running batch jobs and can also have "heavywieght" web screens or message processing.

Here are some of the things we do in Smalltalk. Parse 8 or 10 million records from a UNIX file, massage them, and post them to a database; Parse 50-100 meg of XML files and calculate several tens of millions of numbers based on customer defined rules; Read several million Websphere MQ messages, parse them, converting from EBCDIC to ASCII, massage them, and load them into a database; Process 100+ MQ messages per second as a service for interactive user sessions, with an SLA response time of 99% under 4 seconds and 100% under 20 seconds.

We architect and tune for volume. For example, in the first app, we can process about 300-350 records per second in a single VAST image on a Solaris 1.2 Ghz machine. Yet, that still means it would take 8 hours to process if we didn't split the work and run in parallel.

These long running processes are almost always CPU bound. We continually monitor and tune our apps. But, if Instantiations can help us out with VM improvements, that is a big deal.

I can't say we'll buy additional licenses, and I can't say whether Java is more or less efficient. But, I can predict that next time the MQ based interactive app grows by another 50 transactions a second, and another check needs to be written to Sun, someone without knowledge of either the complexities of the application, or the benefits of Smalltalk development will say, "Why is that written in Smalltalk anyway. I'm sure Java (or COBOL) would be lots more efficient?"

If those of us in the know can point to efficiency improvements we obtained with the most recent release from Instantiations, it is one more arrow in our quiver. It could help us continue to develop new applications in Smaltalk and keep our existing licenses current.

We certainly read the Strongtalk announcement with great interest. How or if we might apply it to VAST is still an open question. Nothing in our deal with IBM would prevent us from using all or part of it (or swapping out the existing VM entirely). Actually doing something like that would be a huge decision and not something we would do lightly. The risk would be tremendous as would be the cost. The ultimate payoff (in terms of any significant performance improvement or an improvement in our ability to sell the product) is also unknown.

I understand. And I know benchmarks are always suspect. Yet, VW is almost always somewhat faster than VAST on benchmarks, and the Strongtalk benchmarks, are, at the least, very suggestive of improvements which can be made. Please keep improving the VM.