Benji Smith wrote:
> Walter Bright wrote:
>> Benji Smith wrote:
>> If you designed a language around COM, you'd get all that stuff for free, too. I agree that using COM in C++ is a bit clunky, but after all, C++ was designed before there was COM.
> 
> Aha. Very interesting point. I hadn't thought of that.
> 
> Is there such a language? Or is this just hypothetical?

It turns out that Java and C# both can map directly onto COM, so if one were to build a native compiler for them, that can be done.

I didn't design D to map directly onto COM because COM is a dying technology.

>> The x86 processors have 4 rings of hardware protection built in. The idea is to do the isolation in hardware, not software, and it does work (one process crashing can't bring down another process). Where it fails is where Windows runs all processes at ring 0. This is a terrible design mistake. The CPU *is* designed to provide the sandboxing that a VM can provide. Also, as VMware has demonstrated, the virtualization of hardware can provide complete sandbox capability.
> 
> Lots of great info. Thanks. I didn't know that the x86 had support for profiling, debugging, sandboxing, etc.

The problem is it's simply easier to just write a VM. But when you've got a billion dollars to spend, there's no need to take the easy route.

> I'd actually argue, though, that these kinds of features are actually VM features, even if they have actually been implemented on silicon. Since these kinds of functions provide an outside observer with a view into the machine's internals, I think they're more naturally implemented in a virtual machine (and VMs will, no doubt, be the environments where the most interesting research is conducted into new techniques for profiling, debugging, instrumentation, etc).

These features existed in the x86 since the mid 1980's, a decade before the Java VM and 15 years before the CLR. Mainframe hardware virtualization has existed for much longer.

> If you want these kinds of meta-platform features baked into silicon, or solidified in your platform, you either need to wait twenty years for the market to prove their viability, or you can get them in next year's VM technologies.

Hardware sandboxing on the x86 has been around at least since the infamous 286 "penalty box". The 286 was Intel's first try at hardware virtualization, and a lot of mistakes were made. The 386 got it right, and the first fruits of that came in Windows-386, which provided multiple virtual DOS sessions.

The original 8086 had no virtualization capability, and as a result, it was a *terrible* platform for software development. Any errant program could pull down the whole system. With the 286 came 'protected mode', where errant pointers were trapped by the hardware. It was the first sandboxing for x86.

> PS: Keep in mind, I'm playing devil's advocate here, not because I have anything against compilation for a native platform, but because I think there are lots of interesting innovation in the VM universe that could be useful to D.

Software VM features can certainly drive forward adoption of hardware features. They always have <g>.

Daniel Keep wrote:
> 
> Funny thing, turns out SSE is actually *slower* for doing a dot product
> than regular old x87 code!

You should qualify this - I'm guessing you mean for a single dot product?  If so, this is the case in most vector coprocessors, as load/store overhead can easily outweigh the gains in vectorization.

--Steve

Stephen Waits wrote:
> Daniel Keep wrote:
>>
>> Funny thing, turns out SSE is actually *slower* for doing a dot product than regular old x87 code!
> 
> You should qualify this - I'm guessing you mean for a single dot product?  If so, this is the case in most vector coprocessors, as load/store overhead can easily outweigh the gains in vectorization.
> 
> --Steve

Sorry; yes, you're right: it's for a single dot product.

I'm surprised at this because of the sheer number of articles I ran across touting "faster" dot product functions using SSE.  I have a feeling these people have never bothered to actually *benchmark* their "faster" functions :P

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Daniel Keep wrote:
> Sorry; yes, you're right: it's for a single dot product.
> 
> I'm surprised at this because of the sheer number of articles I ran
> across touting "faster" dot product functions using SSE.  I have a
> feeling these people have never bothered to actually *benchmark* their
> "faster" functions :P
> 
> 	-- Daniel


I'm also assuming that's for some low-dimensionality vector? I'd likewise guess that there's some sweet spot where dot product calculation is faster with SSE, even for a single pair of vectors, if the vectors are of sufficient dimensionality.

--benji

Benji Smith wrote:
> Daniel Keep wrote:
>> Sorry; yes, you're right: it's for a single dot product.
>>
>> I'm surprised at this because of the sheer number of articles I ran across touting "faster" dot product functions using SSE.  I have a feeling these people have never bothered to actually *benchmark* their "faster" functions :P
>>
>>     -- Daniel
> 
> 
> I'm also assuming that's for some low-dimensionality vector? I'd likewise guess that there's some sweet spot where dot product calculation is faster with SSE, even for a single pair of vectors, if the vectors are of sufficient dimensionality.
> 
> --benji

3D single-precision.  The problem seems to be a combination of unaligned loads, and the trickery you have to resort to in order to sum the XMM register horizontally.  There's a dot product instruction in SSE4, but I don't have a CPU that supports it.  :P

It also doesn't help that the compiler will inline the FPU functions, but won't inline the SSE ones.

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Daniel Keep wrote:
> It also doesn't help that the compiler will inline the FPU functions,
> but won't inline the SSE ones.

Anyways, I admit I miss the "inline" keyword - fortunately it can be
roughly emulated with mixin templates. :)

Regards, Frank

Jan Claeys wrote:
> It's a very interesting project, but RPython is not the same language as Python, and they left out some of the things that make compiling Python to native code so difficult...
AFAIK, just the PyPy compiler for python (amongst other tools) is written in RPython. It can compile all normal (well all of it that is currently supported) Python code. This is the same approach as Squeak does for Smalltalk [1] and Rubinius [2] does for Ruby.

What you described more accurately reflects Shedskin [3], a Python-to-C++ compiler that only supports a subset of Python

 - Paul

1: http://www.squeak.org/Features/TheSqueakVM/
2: http://en.wikipedia.org/wiki/Rubinius
3: http://mark.dufour.googlepages.com/home

Benji Smith skrev:
> Walter Bright wrote:
>> Benji Smith wrote:
<smip>
>> If you designed a language around COM, you'd get all that stuff for free, too. I agree that using COM in C++ is a bit clunky, but after all, C++ was designed before there was COM.
> 
> Aha. Very interesting point. I hadn't thought of that.
> 
> Is there such a language? Or is this just hypothetical?
> 
Visual Basic.

The Visual Basic versions over time is pretty much a mirror of the capabilities of COM as implemented by Microsoft over time.

Including inheriting the limitations; the reasons you can not inherit a class from another class in Visual basic is simply because you can not inherit a component from another component in COM.

And the interfaces and classes (components) you create in Visual Basic are usable COM interfaces and components from C++, or what you like.


// Fredrik