EIZO revealed a new monitor with 1:1 aspect ratio

[Opcode]

According to you. If you customize Emacs and know your own hot keys you can debug lightning fast and ensure you're always passing the right parameters in the right order (no one who does anything significant can memorize the API necessary for said task). Now, if you use visual studio, that's amateur hour.

Apparently 99% of developers are amateurs. There's nothing wrong with Visual Studio. The content you create rely's solely on your own skill set and can't be held to which IDE you use. Tho in proper environments you wouldn't even need to be digging through code to check what parameters an existing UDF requires as the IDE itself should be letting you know. If an IDE cannot carry out even simple tasks like this then it's not much of an effective development environment.

[patrickjp93]

Apparently 99% of developers are amateurs. There's nothing wrong with Visual Studio. The content you create rely's solely on your own skill set and can't be held to which IDE you use. Tho in proper environments you wouldn't even need to be digging through code to check what parameters an existing UDF requires as the IDE itself should be letting you know. If an IDE cannot carry out even simple tasks like this then it's not much of an effective development environment.

Visual studio has a weaker compiler than GCC. Furthermore, it's a slow, cumbersome toolset that isn't conducive to having multiple code panes open at once and fluid workflow. The only thing really nice about VS is the debugger imho.

 

And the IDE can't always let you know when you're working with libraries outside the standard C/C++ packages. Visual Studio is a nightmare to try to do package management with. In Emacs at least you can use Flymake and customize it fairly quickly.

 

You'd also be shocked at the performance increase you can get between compiling on Intel's compiler vs. Microsoft's. In some cases it's as much as a 50% performance improvement. The downside is if you want to be as compatible as possible with AMD architecture you need to slightly modify the compiler to use a different CPU dispatcher since ICPC and ICC both still check CPUID strings instead of just supported instructions.

 

Even Clang gets at least 14% better performance over Microsoft's compiler in all the big compiler benchmarks, which are surprisingly good at representing real world performance.

[Opcode]

Visual studio has a weaker compiler than GCC. Furthermore, it's a slow, cumbersome toolset that isn't conducive to having multiple code panes open at once and fluid workflow. The only thing really nice about VS is the debugger imho.

 

And the IDE can't always let you know when you're working with libraries outside the standard C/C++ packages. Visual Studio is a nightmare to try to do package management with. In Emacs at least you can use Flymake and customize it fairly quickly.

 

You'd also be shocked at the performance increase you can get between compiling on Intel's compiler vs. Microsoft's. In some cases it's as much as a 50% performance improvement. The downside is if you want to be as compatible as possible with AMD architecture you need to slightly modify the compiler to use a different CPU dispatcher since ICPC and ICC both still check CPUID strings instead of just supported instructions.

 

Even Clang gets at least 14% better performance over Microsoft's compiler in all the big compiler benchmarks, which are surprisingly good at representing real world performance.

Use of compiler is irrelevant to the IDE (not a subject being discussed here). You can use whichever compiler you want regardless to the IDE being used.

 

I don't use Visual Studio or most mainstream IDE's as most of them are overworked and bloated with unnecessary features.

 

Compiler of choice depends primarily on the hardware the software was designed to run on. Intel's compiler for Intel based machines, GNU for AMD based machines. In each case of them circumstances the compiler is optimized for said hardware (providing the best performance). Checking CPUID is perfectly fine, you can pull a majority of the supported instructions directly through that opcode.

MOV EAX, 1CPUID~ Check What You Want ~

Like said, the discussion really isn't about compilers. If it was I would simply tell you they all suck and stick to writing completely in assembler. There's no compiler in the world that can beat hand optimized assembler.

[patrickjp93]

Use of compiler is irrelevant to the IDE (not a subject being discussed here). You can use whichever compiler you want regardless to the IDE being used.

 

I don't use Visual Studio or most mainstream IDE's as most of them are overworked and bloated with unnecessary features.

 

Compiler of choice depends primarily on the hardware the software was designed to run on. Intel's compiler for Intel based machines, GNU for AMD based machines. In each case of them circumstances the compiler is optimized for said hardware (providing the best performance). Checking CPUID is perfectly fine, you can pull a majority of the supported instructions directly through that opcode.

MOV EAX, 1CPUID~ Check What You Want ~

Like said, the discussion really isn't about compilers. If it was I would simply tell you they all suck and stick to writing completely in assembler. There's no compiler in the world that can beat hand optimized assembler.

You can patch the Intel compiler to use a different dispatcher, so it doesn't even matter.

 

Also, that's completely untrue. 99% of the time you can't outsmart compilers anymore. Even Linus Torvalds has admitted that. You have AI building compilers now for crying out loud.

 

The only reason most people develop in Visual Studio is because that's what they learned C++ on in college, but there's really no point and in fact it's cumbersome. Also, Clang and Visual Studio do not get along. It's a nightmare trying to trick VS into using it. It also hamstrings the Intel Compiler by using less efficient libraries. 

 

You can't work at peak efficiency in Visual Studio. This has been studied a number of times objectively by hundreds of computer scientists. It's just too damn bloated and poorly organized. Emacs is nice and lightweight while also doing everything and more that VS can do. I prefer it over VI because VI's hotkeys are stupidly allocated and the earning curve is obnoxious for anyone.

[Opcode]

You can patch the Intel compiler to use a different dispatcher, so it doesn't even matter.

 

Also, that's completely untrue. 99% of the time you can't outsmart compilers anymore. Even Linus Torvalds has admitted that. You have AI building compilers now for crying out loud.

While a compiler is good at optimizing code regardless of how you write it. It will never beat hand optimized assembler, simply put never.

[patrickjp93]

While a compiler is good at optimizing code regardless of how you write it. It will never beat hand optimized assembler, simply put never.

That is fully dependent on your expertise in assembly vs. that of the people who made the compiler in the first place. It's exceptionally rare that you can beat a compiler without forcing yourself into a race condition that can cause unstable results.

[Opcode]

That is fully dependent on your expertise in assembly vs. that of the people who made the compiler in the first place. It's exceptionally rare that you can beat a compiler without forcing yourself into a race condition that can cause unstable results.

Software is only as good as the people who write it. Compilers fall subject to this rule in general as well. While being smart enough to take even the worst of source code and optimizing it for the best performance possible. A compiler can never hold a candle to hand optimized assembler in terms of raw performance. Hand optimized assembler will always be faster than generated code and that's just a general rule in programming that will never change.

[patrickjp93]

Software is only as good as the people who write it. Compilers fall subject to this rule in general as well. While being smart enough to take even the worst of source code and optimizing it for the best performance possible. A compiler can never hold a candle to hand optimized assembler in terms of raw performance. Hand optimized assembler will always be faster than generated code and that's just a general rule in programming that will never change.

Not always. I'd be frankly surprised if you took your best C++, compiled via ICPC with the maximum optimization flags called and could outdo the assembly it generated. Now, that doesn't mean someone cannot come along and do it, but that gap in performance is narrowing, and the human brain can only do assembly for so long before it can't keep track of it all anymore.

 

Now, for a single algorithm, I can see it being more doable, but I'd still bet you cause yourself problems and instability more often than not.

[Thony]

R.I.P. gaming if u buy this. But maybe in triple setup its ok

[Musikman]

The only time this would be good for gaming would be in a game like Civilization. The target audience for this monitor is professional users. I personally could make use of it in CAD applications where having the space to look at drawings or models would be very useful. Bezels are a bear when they interrupt text or dimensions.

[Opcode]

Not always. I'd be frankly surprised if you took your best C++, compiled via ICPC with the maximum optimization flags called and could outdo the assembly it generated. Now, that doesn't mean someone cannot come along and do it, but that gap in performance is narrowing, and the human brain can only do assembly for so long before it can't keep track of it all anymore.

 

Now, for a single algorithm, I can see it being more doable, but I'd still bet you cause yourself problems and instability more often than not.

If you honestly think generated code can always out do hand optimized assembler then you must new to the world of programming. The performance gap between the two may narrow but never entirely as compilers will continue to always do wonky shit to make even the worst of written code compatible. A compiler is nothing more than a third person who restructures your code and does some under the hood optimizations before compiling it to machine code. With assembler there is no room for mistakes or unconventional methods. Either you do it right or it simply doesn't work. Lots of mainstream software writes their instruction intensive tasks completely in assembler for the sake of performance. The main problem with compilers is you need to feed it the right source in order for it to generate high performance code. If you're going to do vector based calculations with standard operators in comparison to bit shifts the code generated will be multiple times slower through the same exact compiler. So there's more to it than just compiler vs compiler. If you use unconventional programming methods regardless of what you do it in the output will always be the same.

[connorpiper]

It would be useful in medical situations such as control panels for MRI scanners. Or Xray revision monitors. 

 

But Hitachi already does this...

[fringie]

nvm answered

[plutomok]

perfect for....instagram...?

[Biased Opinion]

useful for some, not for me though. I don't really need massive amounts of vertical space (although more than 1080 would be nice). What i need is massive amounst of horizonal space because im a tab fiend and i need the space.

[kennethnakasone]

-woah-

 

I'd buy it.

 

Also, do you know what happened to LG's 1:1 aspect ratio monitor? I think it had similar specs.

[SpaceCore]

wat?

[Maslofski]

does it have swivel?

[Sharkyx1]

For fun, here's some games at 1:1

[Nivius]

if i ware to use this, i whould just think.... why not....  ????x1920 16:9