Benchmarking will inevitably be required, I'm aware, but I was curious what other's experiences with performance comparisons between physics calculations that are performed in compiled (C++) languages vs those that run entirely in a virtual machine (namely LUA). Do the benefits of speed in C++ outweigh the accessibility and ease of modification in Lua? And what, in your experience, is to be expected from this difference of speed? I have always done my physics in C++, but I realize now that it may well be a wise decision to move those calculations into the Lua engine. It would also reduce the (albeit minor) overhead of communication between C++ based collider objects and Lua based game logic objects.

Naturally speed will depend on coding efficiency, but I'm curious as to what others have experienced. Thank you for any input.

An alternative might be to consider using Runtime Compiled C++, which would also allow you to have your game objects in C++ as well as the physics.

If your game doesn't require significant computation resources, then moving completely to a scripting language might be another approach. There's plenty of information out there on performance of scripts vs compiled C++, though it does depend on your platform. For example consoles cannot JIT compile due to data execution prevention for security purposes.

A single bouncing ball for pong physics is VERY different from a ragdoll simulation.

The physics for a few hardcoded object falling is different from a physics simulation handling thousands of complex meshes with joints and springs and constraints.

Fair enough. I tried to keep my first post information light to stay on topic, but I understand how you would need more than I gave. Here's the dump:

I'm looking to implement something scalable that can be used as the basis for the physics engine of an FPS game - however, as I tend to recycle a lot of code from game to game, I imagine that a successful implementation will carry over to other games. For simplicity, I'm simulating only rigid bodies (water and fabric would be calculated separately) from about the size of a bullet to a car. The number of objects for this project is expected to be quite large, but for simplicity will rely mostly on rectangular prisms rather than complex meshes. I'm most familiar with verlet based physics (and there's an awesome article on that here on GD for anyone interested - extensions to 3D are not difficult) and would be using them in this simulation. The target platform for all of my development is linux, however, porting to Windows and Mac is always desirable.

The question, with respect to this game and future projects, is what experiences individuals have had running a full physics simulation in a scripted language (either Lua, Python or similar) and whether they would advise keeping the actual simulation compiled in C++ or scripted. I ask because I have been migrating more and more code into scripted languages and over the course of several discussions have come to realize that I am likely still under-utilizing scripts.

As others have said, it depends on your physics, so we can't know for sure.
The "scientific" approach would be to code as much as you can in LUA, profile it, and, if necessary move the slow code to C++. That is, the basic building blocks (matrix arithemtic, triangulation, collision detection,...) of it. Which ammounts to creating a robust, small physics library in C/C++ with lua bindings.

I ask because I have been migrating more and more code into scripted languages and over the course of several discussions have come to realize that I am likely still under-utilizing scripts.

I think it's important to ask yourself what your priorities are. Scripting languages have a number of issues of which performance is only one, especially when combined with other languages due to debugging and interface barriers. For this reason many of my colleagues and friends in the games industry have been moving away from scripts to trying to use data driven systems and graphical interfaces (such as Unreal Kismet / Crytek Flowgraph etc.) for designer editing of behaviours.

A high performance physic system seems an ideal space for using a compiled language like C or C++ with all the tools available, and low level capabilities such as intrinsic access to SIMD arithmetic and efficient multi-threading. If you're looking for an easier way to program SIMD then you may want to look at ISPC.

The question, with respect to this game and future projects, is what experiences individuals have had running a full physics simulation in a scripted language (either Lua, Python or similar) and whether they would advise keeping the actual simulation compiled in C++ or scripted. I ask because I have been migrating more and more code into scripted languages and over the course of several discussions have come to realize that I am likely still under-utilizing scripts.

As a rule of thumb: use scripting languages to control the simulation, not to run it. When it comes to physics you can for example use lua to add forces, enable/disable kinematics, add new objects, etc.

I don't suffer from insanity, I'm enjoying every minute of it.The voices in my head may not be real, but they have some good ideas!

My inclination is (based on experience) - scripted languages are useful when you need to ship an application whose behaviour must be modifiable by the user (beyond just being data driven). However, in every other area, they offer only marginal benefit at best given tools available with compiled languages (C/C++) - dlls, variable modification in the debugger, edit & continue. E&C in particular is incredibly useful (having worked on physics engines, AI and more).

On another topic - I would strongly advise against trying to use verlet integration and particles for 3D rigid body physics. In my experience, it ends up being much more complicated than impulse based methods (for which there's plenty of reference/info), slower and less well behaved. It seems way easier at first - but refining it involves hacks layered upon hacks... (I have some info, admittedly old now, that might be useful here)