Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Midipix: Posix for Windows

midipix.org

Post reply on HN
Print view View original

31–40 of 92 posts

Re: Midipix: Posix for Windows

#31

Post by nanny »

TickleSteve wrote: post #19
wfunction wrote: post #17

Earlier quoted context omitted.

And where is the copy-on-write happening here? If I recall correctly, the problem was that attempting to reproduce fork()'s copy-on-write behavior on Windows resulted in a massive performance hit. (Which, IIRC, contributes to the slowness of Cygwin.) EDIT: Oh, I'd skipped the part above "here's how it works"... that just says exactly the same thing I said above.

I've personally never had any real performance issues with Cygwin. What are you doing that involves lots of forking? For me, Cygwin has always been pretty much native-speed, its only an API translation layer.

I have few "real" performance issues with Cygwin as well. However, when I perform the same tasks in gnu/linux there is a noticeable speed increase. So what I mean to say is that Cygwin's performance isn't necessarily bad, it's just not as good as the real thing.

Re: Midipix: Posix for Windows

#32

Post by nanny »

wumbernang wrote: post #14
greggman wrote: post #10

Earlier quoted context omitted.

Compare it to linux git, it's about 10-20x slower on same hardware

That's probably the NTFS MFT rather than the actual runtime. Git plops lots of small files on the disk which end up in the MFT. The MFT is really slow. We have the same trouble with SVN. You can tune this a bit with fsutil and turn off last access time, 8dot3 filenames and change mftzone size and it'll be significantly faster. ReFS is a little better in this respect. I suspect this was a hang-back from early NT versi…

Thanks so much for this, I was always curious why git's so slow on Windows.

Re: Midipix: Posix for Windows

#33

Post by pjmlp »

userbinator wrote: post #29
wfunction wrote: post #15

This project sounds too good to be true. I would be quite astonished if they can make fork() work seamlessly without an amazingly high performance cost. In my experience the only way to do such a thing is to use NtCreateProcess(), but that function itself seems impossible for anyone besides Microsoft to use correctly. (I have tried numerous times and failed, and so have many others.)

This is part of the reason why I don't think compatibility layers like this are worth bothering with if you're after performance - different OSs do things in different ways, and while it's possible to make one work like another, it's sub-optimal because that wasn't the use-case the OS was designed for. It's really a high-level design decision: Applications originally designed for *nix will use fork(), while those for…

Not only that, like Mac OS X, Windows is moving into another application model WinRT with containers. Just like Carbon, only selected Win32 APIs will survive in the long run.

Which leaves the question how much POSIX can be implemented on top of WinRT.

Similarly not all POSIX calls are allowed inside Mac OS X App Sandbox.

And if we restrain ourselves to POSIX there is little more than command line applications, TCP/IP headless servers and Motif GUIs.

Re: Midipix: Posix for Windows

#34

Post by novocaine »

TickleSteve wrote: post #19
wfunction wrote: post #17

Earlier quoted context omitted.

And where is the copy-on-write happening here? If I recall correctly, the problem was that attempting to reproduce fork()'s copy-on-write behavior on Windows resulted in a massive performance hit. (Which, IIRC, contributes to the slowness of Cygwin.) EDIT: Oh, I'd skipped the part above "here's how it works"... that just says exactly the same thing I said above.

I've personally never had any real performance issues with Cygwin. What are you doing that involves lots of forking? For me, Cygwin has always been pretty much native-speed, its only an API translation layer.

GNU make.

Keep in mind that in addition to the build steps, it's common to break out to sed, grep, and shell to get basic string operations done due to extremely limited capability of make itself. On cygwin, this is slow for large projects.

Cygwin's forking is also temperamental.

https://cygwin.com/cygwin-ug-net/highlights.html#ov-hi-proce...

"In summary, current Windows implementations make it impossible to implement a perfectly reliable fork, and occasional fork failures are inevitable."

I wonder how the authors of midipix propose to resolve the listed issues.

Re: Midipix: Posix for Windows

#36

Post by netheril96 »

pjmlp wrote: post #33
userbinator wrote: post #29

Earlier quoted context omitted.

This is part of the reason why I don't think compatibility layers like this are worth bothering with if you're after performance - different OSs do things in different ways, and while it's possible to make one work like another, it's sub-optimal because that wasn't the use-case the OS was designed for. It's really a high-level design decision: Applications originally designed for *nix will use fork(), while those for…

Not only that, like Mac OS X, Windows is moving into another application model WinRT with containers. Just like Carbon, only selected Win32 APIs will survive in the long run. Which leaves the question how much POSIX can be implemented on top of WinRT. Similarly not all POSIX calls are allowed inside Mac OS X App Sandbox. And if we restrain ourselves to POSIX there is little more than command line applications, TCP/IP…

> Which leaves the question how much POSIX can be implemented on top of WinRT.

> Similarly not all POSIX calls are allowed inside Mac OS X App Sandbox.

Except that WinRT as well as OS X Sandboxed App are all unpopular and therefore unlikely to replace the regular apps anywhere near in the future.

Re: Midipix: Posix for Windows

#37

Post by pjmlp »

netheril96 wrote: post #36
pjmlp wrote: post #33

Earlier quoted context omitted.

Not only that, like Mac OS X, Windows is moving into another application model WinRT with containers. Just like Carbon, only selected Win32 APIs will survive in the long run. Which leaves the question how much POSIX can be implemented on top of WinRT. Similarly not all POSIX calls are allowed inside Mac OS X App Sandbox. And if we restrain ourselves to POSIX there is little more than command line applications, TCP/IP…

> Which leaves the question how much POSIX can be implemented on top of WinRT. > Similarly not all POSIX calls are allowed inside Mac OS X App Sandbox. Except that WinRT as well as OS X Sandboxed App are all unpopular and therefore unlikely to replace the regular apps anywhere near in the future.

If you prefer another set of examples, iOS, Android, Arduino, HTML 5.

For me POSIX is a kind of unofficial C runtime.

Now with systems moving beyond C, POSIX matters much less.

Re: Midipix: Posix for Windows

#38

Post by userbinator »

opaque_salmon wrote: post #2

That's an interesting name choice that might make it hard for me to remember in the future, do you happen to know why they chose it? In any case, I welcome a posix interface for windows, it would be a cool tool to have, especially in the case of cross-platform utilities.

I agree about the name - it sounds more suitable for MIDI visualisation software.

Cygwin and MingW don't evoke any existing meaning, so I think they're somewhat more memorable.

Re: Midipix: Posix for Windows

#39

Post by cwyers »

pjmlp wrote: post #33
userbinator wrote: post #29

Earlier quoted context omitted.

This is part of the reason why I don't think compatibility layers like this are worth bothering with if you're after performance - different OSs do things in different ways, and while it's possible to make one work like another, it's sub-optimal because that wasn't the use-case the OS was designed for. It's really a high-level design decision: Applications originally designed for *nix will use fork(), while those for…

Not only that, like Mac OS X, Windows is moving into another application model WinRT with containers. Just like Carbon, only selected Win32 APIs will survive in the long run. Which leaves the question how much POSIX can be implemented on top of WinRT. Similarly not all POSIX calls are allowed inside Mac OS X App Sandbox. And if we restrain ourselves to POSIX there is little more than command line applications, TCP/IP…

> Not only that, like Mac OS X, Windows is moving into another application model WinRT with containers. Just like Carbon, only selected Win32 APIs will survive in the long run.

Microsoft would still let you run 16-bit DOS apps on Windows if Intel hadn't dropped compatibility from their 64-bit processors. Both of us will be dead and buried before Win32 goes away.

Re: Midipix: Posix for Windows

#40

Post by cwyers »

tkubacki wrote: post #9

Deploying Linux apps on Windows Server is easier these days (Hyper-V). If you really need decent POSIX OS on Windows just use virtualiztion.

I'm sympathetic to people who want to develop portable GUI apps across Linux/Windows/OS X. If you're developing something like Inkscape or LibreOffice, most of your potential user base is on Windows and they are NOT going to install a Linux VM just to run your app.

But yeah, there are a lot of people on HN who constantly post about how their work issued them a cat and they have all these tools they install on their cat to make it act more like a dog but it makes a really terrible dog anyway and so cats must be crap. Uh, it's a cat. If you need a dog, go get a dog. Or run a dog on Hyper-V if you need a dog and a cat at the same time. My favorite is when people talk about how their favorite scheme they use to get their dog to catch mice doesn't work for their cat, therefore it's evidence that cats are terrible at catching mice.

Post reply on HN