home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / linux / extra / docs / maillist / text / archive.94 / text0124.txt < prev    next >
Encoding:
Text File  |  1996-04-02  |  2.2 KB  |  50 lines
  1. >Does executor store the native code
  2. >it generates on disk or does it regenerate on every restart of the
  3. >program?
  4.  
  5. It generates native code every time the program is run.  68k code is
  6. only dynamically compiled as it is first executed, which is why you
  7. don't notice a huge lag on program start-up.
  8.  
  9. >It seems to me that such a comparison (say 486/66 running
  10. >the synthetic benchmarks vs IBM code on same benchmarks) would show
  11. >how much farther the synthetic CPU has to go before matching the
  12. >performance of compiled code for the IBM.
  13.  
  14. We don't have the source code to Speedometer, so we can't recompile it
  15. native for the x86.  Although the ratio of emulated speed to native
  16. speed is certainly an interesting number for me (the emulator author),
  17. absolute performance is what matters to the end user.  We can give
  18. people near-Quadra performance on a 486 DX/2 66, and that's good
  19. enough for most people.  For programs that spend time in the "ROMs",
  20. our performance is even better than these numbers indicate.
  21.  
  22. >In theory, it seems to me
  23. >that the synthetic CPU should be able to match the real one (it would
  24. >take alot of analysis... data flow and control flow analysis just like
  25. >in a real compiler/optimizer). Am I way off base here? Or is such
  26. >analysis too complicated for now?
  27.  
  28. "In theory" much is possible, but the analysis would be too extensive
  29. to perform at runtime.  Remember, we're emulating a big endian
  30. processor with 16 registers on a little endian processor with 8
  31. registers.  Maintaining a big endian memory image necessitates extra
  32. work, and full inter-block register allocation would (probably) be too
  33. slow to do at runtime.  A fair comparison might be an x86 version of
  34. the same benchmark coded in such a way as to maintain a big endian
  35. memory image.
  36.  
  37. >Are there reaons besides time
  38. >constraints that heavy optimization isn't performed and then the
  39. >results stored on disk?
  40.  
  41. No.  Dynamic compilation is responsive enough and our performance is
  42. good enough that we haven't allocated resources to opening this can of
  43. worms.  We *could* do this someday to augment our emulator's
  44. performance, and I would personally find such a project interesting,
  45. but for now that's low priority.
  46.  
  47. -Mat
  48. mat@ardi.com
  49.  
  50.