OpenEuphoria

Re: Upcoming releases

• Posted by Robert Craig <robert_craig at COMPUSERVE.COM> Jun 11, 1997
• 1204 views

Daniel Berstein writes:
> Can you specify them? I guess it includes the concatenation "&".

(please ignore the equals signs and 3D things that keep getting
 inserted in my messages)

 Version 1.5a:

* Many operations and library routines are now much faster. Performance
  figures below are based on a 150 MHz Pentium machine running Windows 95=

  and using a cheap S3 video card.

  Thanks to Michael Bolin, get_key() is 100x faster when there is no key
  in the buffer (the usual case).

  Thanks to Michael Bolin, get_all_palette() is over 100x faster and this=

  makes save_screen() much faster.

  The following routines have now been built directly into ex.exe, to avo=
id
  the overhead of calling machine_proc() or machine_func(). There is no l=
onger
  a requirement to include graphics.e or machine.e to call: pixel(),
  get_pixel(), mem_set() or mem_copy(). This makes calls to these routine=
s
  much faster, especially when small numbers of bytes or pixels are invol=
ved.
  For example, mem_copy() of 20 bytes or less is at least 2.5x faster and=

  mem_set() of 20 bytes or less is at least 10x faster.

  pixel() is much faster in all graphics modes, and is now extremely fast=
 in
  mode 19. pixel() is almost as fast as using poke() in mode 19, and pixe=
l()
  will safely ignore any pixels that are written off-screen. mem_copy()
  and mem_set() remain the fastest ways to write an image onto the mode 1=
9
  screen, but you must already have the image stored in memory. Plotting =
a
  single pixel is 70% faster in most modes, and 4.5x faster in mode 19.
  Plotting a sequence of 10 pixels is 50% faster in most modes, and over
  4x faster in mode 19 compared to version 1.5.
  poke() of a long sequence into memory, other than video memory, is 50%
  faster. poke() into video memory is not any faster.

  get_pixel() is faster in all modes, especially where a single pixel
  value is read.

  display_image() is faster because pixel() is faster. A 10x10 image
  can be displayed at least 30% to 40% faster in any graphics mode,
  and over 4x faster in mode 19.

  All arithmetic and bitwise operations applied to sequences of integers =
are
  now faster. For example, adding a long sequence of integers to another =
long
  sequence of integers is 29% faster.

  a & b (concatenation) is 15% faster in most cases, and is dramatically
  faster in the case where you grow a very long sequence by concatenating=

  many small sequences onto it.

  getc() is 12% faster.

  match() is 8% faster in typical cases.

  append()/prepend() are 15% faster in many cases.

  find() of an integer within a sequence of integers is 64% faster.

  formation of a 2-element sequence {a,b} is 11% faster

  Internal copying of a shared sequence when it can no longer be shared i=
s
  15% faster. Some other internal operations of the interpreter are also
  somewhat faster.

* The following demo programs have been improved slightly:
  mouse.ex, mydata.ex, eprint.ex, search.ex

* BUG FIXED: If a run-time error occurred at the top-level of a program, =
on a
  line containing multiple statements, the ex.err traceback might fail.

* BUG FIXED: While tracing, the library routines call(), mem_copy() and
  mem_set() might write to the trace screen, rather than writing to the
  main output screen.

* The documentation for get_mouse() has been improved.


> I still don't get this... I'm using Win95 with Euphoria 1.5 in a
> text console... what's the difference???

You're right. For many existing programs there won't be a visible =

difference between using ex.exe and using the new win32 version =

of ex.exe. However the key thing is that you'll be able to call =

C routines in WIN32 DLLs. There are a few other minor advantages =

too, such as full support for long filenames, and 20% faster
floating-point calculations.

> When is coming a Linux version (cool)???

It's hard to say. I want to get the WIN32 alpha out before
looking more at Linux.

Regards,
  Rob Craig
  Rapid Deployment Software