Thread View: comp.lang.oberon
3 messages
3 total messages
Started by John Garst
Wed, 03 Apr 1996 18:36
Newbie - speed question
Author: John Garst
Date: Wed, 03 Apr 1996 18:36
Date: Wed, 03 Apr 1996 18:36
21 lines
1396 bytes
1396 bytes
I have a PowerMac 7100/66 and an Amiga 3000. I do some not-very-complex
floating-point number crunching now and then. I've been using a compiled
BASIC (HiSoft) on the Amiga, but no compiled BASIC is yet available for
the PowerMac. I've just found PowerOberon. This is completely new to me,
and in order to use it, I would have to learn a lot. I *have* programmed
in another Wirth language, Pascal, occasionally.
Can anyone provide (even a very gross) estimate of the execution speed
advantage that might be obtained by using PowerOberon, compared with a
compiled BASIC on the Amiga 3000 (and the PowerMac 7100/66, should one
become available soon)?
Is Oberon a good number crunching language?
Do I face a very steep learning curve if I try to use it?
*********************************************************************
John Garst garst@sunchem.chem.uga.edu
*********************************************************************
Laws of Tradition: (1) Nothing is ever lost.
(2) Nothing ever stays the same.
Re: Newbie - speed question
Author: Gregory S. DeLozier
Date: Fri, 05 Apr 1996 05:38
Date: Fri, 05 Apr 1996 05:38
81 lines
4294 bytes
4294 bytes
garst@sunchem.chem.uga.edu (John Garst) wrote: >Can anyone provide (even a very gross) estimate of the execution speed >advantage that might be obtained by using PowerOberon, compared with a >compiled BASIC on the Amiga 3000 (and the PowerMac 7100/66, should one >become available soon)? My experience is that the speed of Oberon in general, and Oberon on the 7100 (I have one) is pretty respectable. I don't notice any conspicuous problems in doing numerical applications that include things like splines, Fourier transforms, FIR filters, and the like. I also have done image processing and neural network work in this language and it hasn't given me a bad time. >Is Oberon a good number crunching language? It depends. I like using it because I can write small data-manupulation modules that can operate on data managed by other modules. The data-holding modules can stay in memory while I write, compile, and run the analysis routines. This way, the time I used to spend loading and preparing data to test the analysis routines is dramatically reduced. I don't know of another convenient compiled language that lets me do this. OTOH, this sort of assumes you want to work in the Oberon environment. I enjoy doing this and find it pretty workable, but your mileage (and tastes in user interfaces) may vary. Certainly without a 3-button mouse it will drive you _mad_. (I have invested heavily in Logitech!) I have used the external linker to take MacOberon modules and make them into Mac programs, and it works OK, but you can't debug things that way, and you'd better be ready to wallow in the depths of the Mac Toolbox to get anything done. I was a pretty experienced Mac programmer, and I made a nice framework to make this (sort of) easy, but I didn't have a lot of fun there. (We did this to make a commercial Mac product out of Oberon code. The resulting program is actually pretty nice, but if you're just trying to get your own work done, it's not worth the trouble.) >Do I face a very steep learning curve if I try to use it? Not really. It has lots of on-line docs and examples. I'd ignore most of the how-to-use-the-user-interface stuff for a while and just do reads and writes from the In and Out modules until you're sure the language can cut what you want to do numerically. _Then_ program the fancy display windows... FWIW, I've seen the complex_numbers_vs_no_complex numbers bit come up quite a lot here. It's pretty interesting to note that in the Numerical Recipes book (the original one, in Fortran) virtually no use was made of the Fortran complex type. I've been able to translate just about any numeric code I've seen in any procedural language into Oberon without much trouble, and haven't missed native complex numbers at all. YMMV, I guess. (Note: I did a real-world project at a former employer using Oberon & Gadgets on a SparcStation, and completed _way_ early and under budget, for a neural-net and image-processing application. So there's a data point for you.) (Note #2: I'm teaching a software engineering class where the students have learned some Oberon & Gadgets and are implementing a small spreadsheet. They don't seem to be having any particular problems, which is remarkable, since they are coding collaboratively on about four different platforms.) (Aside comment: IMHO, you'll be a long time waiting for those native-code Basic compilers (unless you're impressed with FutureBasic, which I'm not.) >********************************************************************* >John Garst garst@sunchem.chem.uga.edu >********************************************************************* >Laws of Tradition: (1) Nothing is ever lost. > (2) Nothing ever stays the same. Hope this helps! Sorry about the verbosity! Best wishes, -greg ---
Re: Newbie - speed question
Author: Gregory S. DeLozier
Date: Fri, 05 Apr 1996 05:46
Date: Fri, 05 Apr 1996 05:46
81 lines
4294 bytes
4294 bytes
garst@sunchem.chem.uga.edu (John Garst) wrote: >Can anyone provide (even a very gross) estimate of the execution speed >advantage that might be obtained by using PowerOberon, compared with a >compiled BASIC on the Amiga 3000 (and the PowerMac 7100/66, should one >become available soon)? My experience is that the speed of Oberon in general, and Oberon on the 7100 (I have one) is pretty respectable. I don't notice any conspicuous problems in doing numerical applications that include things like splines, Fourier transforms, FIR filters, and the like. I also have done image processing and neural network work in this language and it hasn't given me a bad time. >Is Oberon a good number crunching language? It depends. I like using it because I can write small data-manupulation modules that can operate on data managed by other modules. The data-holding modules can stay in memory while I write, compile, and run the analysis routines. This way, the time I used to spend loading and preparing data to test the analysis routines is dramatically reduced. I don't know of another convenient compiled language that lets me do this. OTOH, this sort of assumes you want to work in the Oberon environment. I enjoy doing this and find it pretty workable, but your mileage (and tastes in user interfaces) may vary. Certainly without a 3-button mouse it will drive you _mad_. (I have invested heavily in Logitech!) I have used the external linker to take MacOberon modules and make them into Mac programs, and it works OK, but you can't debug things that way, and you'd better be ready to wallow in the depths of the Mac Toolbox to get anything done. I was a pretty experienced Mac programmer, and I made a nice framework to make this (sort of) easy, but I didn't have a lot of fun there. (We did this to make a commercial Mac product out of Oberon code. The resulting program is actually pretty nice, but if you're just trying to get your own work done, it's not worth the trouble.) >Do I face a very steep learning curve if I try to use it? Not really. It has lots of on-line docs and examples. I'd ignore most of the how-to-use-the-user-interface stuff for a while and just do reads and writes from the In and Out modules until you're sure the language can cut what you want to do numerically. _Then_ program the fancy display windows... FWIW, I've seen the complex_numbers_vs_no_complex numbers bit come up quite a lot here. It's pretty interesting to note that in the Numerical Recipes book (the original one, in Fortran) virtually no use was made of the Fortran complex type. I've been able to translate just about any numeric code I've seen in any procedural language into Oberon without much trouble, and haven't missed native complex numbers at all. YMMV, I guess. (Note: I did a real-world project at a former employer using Oberon & Gadgets on a SparcStation, and completed _way_ early and under budget, for a neural-net and image-processing application. So there's a data point for you.) (Note #2: I'm teaching a software engineering class where the students have learned some Oberon & Gadgets and are implementing a small spreadsheet. They don't seem to be having any particular problems, which is remarkable, since they are coding collaboratively on about four different platforms.) (Aside comment: IMHO, you'll be a long time waiting for those native-code Basic compilers (unless you're impressed with FutureBasic, which I'm not.) >********************************************************************* >John Garst garst@sunchem.chem.uga.edu >********************************************************************* >Laws of Tradition: (1) Nothing is ever lost. > (2) Nothing ever stays the same. Hope this helps! Sorry about the verbosity! Best wishes, -greg ---
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads