New Sub-Forum

In an effort to help make sure there are appropriate categories for topics of discussion that are happening, there is now a sub-forum for databases and database programming under Special Interest groups. Please direct questions, etc., about this topic to that sub-forum moving forward. Thank you.
See more
See less

Floating point curiosity

  • Filter
  • Time
  • Show
Clear All
new posts

  • Floating point curiosity

    Dear all,
    I always assumed that the FPU was only used if I explicitly used floating point maths in my code but I've always had an FPU so I'd never tested it. Last week I came to run a PB3.5 program on a 486SX machine with no FPU. The program has NO floating point in it, it's mostly ASM and the only PB code is to count how many times the ASM code has run and print it. The machine reports 'No 8087' as expected. I tried "set 87=true" to fool it into starting the program, but it then crashes. If I compile with the Emulated maths package the code runs very slowly, if I compile it with the Procedure maths package it's 25% faster, but still MUCH slower than it should be. If I swap the 486SX for a same speed 486DX which has an FPU then the program runs at around the speed I'd expect (5 times faster than on the 486SX) but there is still a slight speed penalty if compiled using Procedure FP.
    Now the questions. Why is the execution time varied at all by changing from Emulated FP to Procedural FP when there is no use of floating point in the program? How can swapping the 486SX2-50 for a 486DX2-50 (the only difference I'm aware of is the Hardware FPU) cause the speed of program which uses NO Floating Point to increase 5 fold?


  • #2
    It all comes down to WHERE the number crunching actually takes
    place. The math-co in a DX processor is designed and optimized
    to do the math and the processor automatically sends this info
    to the math-co for processing and gets the results. In an SX
    machine, since the math-co is disabled or not there, the CPU
    itself has to do the number crunching. Since the CPU is not
    really optimized for number crunching (i.e. math) things are
    naturally slower.

    There are no atheists in a fox hole or the morning of a math test.
    If my flag offends you, I'll help you pack.


    • #3
      Dear all,
      I found the problem by disassembling the resulting exe file. Although I was VERY careful to avoid any floating point maths and even any non-integer variables, I did have a single instruction, incr n&& , which incremented a quad integer. It appears that PB3.5 uses the floating point unit to do this. Worse, it takes 5 times longer to do this one increment in the absence of FP hardware than to run the 70 ASM instructions I was looping around. Changing this one variable to n& speeded things up 600% and now Procedure or Emulator options make little difference.