
Unreal Engine 4 on OpenPOWER - amock
https://www.raptorengineering.com/TALOS/op_ue4_gl.php
======
rdtsc
Nice. There was an Anandech article here not too long ago showing pretty nice
improvement over Intel in some cases:

\---

All in all, the maximum throughput of one POWER8 core is about 43% faster than
a similar Broadwell-based Xeon E5 v4. Considering that using more cores hardly
ever results in perfect scaling, a POWER8 CPU should be able to keep up with a
Xeon with 40 to 60% more cores.

\---

[http://www.anandtech.com/show/10435/assessing-ibms-
power8-pa...](http://www.anandtech.com/show/10435/assessing-ibms-
power8-part-1/11)

~~~
doikor
Big thing to also take from that article is that the POWER8 uses over 2 times
as much power as the Xeon E5 v4. Depending on the use case this can be very
important.

~~~
snuxoll
If single-threaded performance or memory bandwidth is more important to your
use case then POWER8 would steamroll a Xeon E5 v4 even factoring in the power
usage, I'm actually looking at trying to get a S812LC at work to eval moving
one of our very heavy transactional PostgreSQL databases to for this very
reason (having to run a seq scan over a 80GB table would benefit heavily from
the increased memory bandwidth).

~~~
gpderetta
As per article linked by the OP, the single threaded performance of the POWER8
is 87% of the Intel CPU at the same clock [1].

The per-core performance is higher thanks to the 8 thread SMT capability of
POWER8 (although the sweet spot is normally 4) and its massive 8-way
execution. So POWER8 is excellent for heavily threaded applications, but for
pure single thread speed, Intel is still king.

[1] IIRC POWER8 and Intel CPUs peak at around the same clock speed.

------
vvanders
Back when I worked on a UE3 title we actually used machines not too far
off(basically more RAM) from final specs so that we wouldn't build things that
could never be run on a reasonable PC/X360/etc. Giving a developer a machine
close to an end users definitely incentivises a focus on fast, performant
code.

However having faster asset cooking is always a good thing.

~~~
jaegerpicker
Faster build machines should always available to devs. Machines to test on
should be the average of the end users.

~~~
vvanders
Yup, we'd use IncrediBuild to keep build times down to something reasonable.

Unless you're working on something very console specific most of your day to
day testing happens on PC. Even titles that don't have a PC port will have a
PC version of the game since iteration time is so much quicker. Having
something close in specs there means you'll see perf issues right up-front as
opposed to when QA gets around to testing it the next day.

~~~
jeremiep
I recently worked on a AAA port where we had roughly 220Ghz worth of
processing power hooked on IncrediBuild; a full rebuild still took about 15
minutes!

We had to make the engine sit on the PSVita and for that reason did all the
development, debugging and testing on that platform. We even debugged a
release build most of the time because the debug one wouldn't go above 5fps!

------
shmerl
_> OpenPOWER systems allow you to keep your valuable assets and proprietary
engine code safe and secure through full owner control_

What does it mean? It's some form of DRM pitch?

~~~
amock
Yes. It's about not having anything like Intel's ME running code you can't
audit or control that has full access to your hardware. It's basically the
same pitch as for Libreboot [https://libreboot.org/](https://libreboot.org/).

~~~
shmerl
I.e. it's DRM-free pitch? That's the opposite of what I first took it for.

~~~
PeCaN
Yes, it's a DRM-free pitch. I suppose “Keep your … proprietary code safe”
could seem DRM-related but “full owner control” is an FSF-y anti-DRM
catchphrase.

~~~
cyphar
It's a very odd mix, pitching user freedom with "proprietary engine code" as
the example of data that is protected.

------
EvgeniyZh
If you're interested in it - support this pull request:
[https://github.com/EpicGames/UnrealEngine/pull/2585](https://github.com/EpicGames/UnrealEngine/pull/2585)

~~~
ivl
If you're getting a 404, it's not because of an error in the URL.

You need to sign up here:
[https://github.com/EpicGames/Signup](https://github.com/EpicGames/Signup)

~~~
cyphar
I'm not going to sign up because their marketing pitch for making the engine
"free[sic]" doesn't specify if they mean it is actually free software or just
gratis + some proprietary source code you get a copy of.

Do you know which is the case? My hunch is it's probably the latter because
they ask for royalties.

~~~
bluesilver07
It's free as in beer, and you get to look at the source code. It's not libre
software.

~~~
cyphar
_sigh_ Figured as much.

~~~
stevehawk
? you expect them to GPL a triple A game engine?

~~~
cyphar
Yes. Why not?

~~~
EvgeniyZh
Because they've spent tons of money on it and now want to earn something

~~~
cyphar
>implying nobody can make money while respecting user freedom

This has been debunked so many times I'm not going to bother.

~~~
EvgeniyZh
Let me rephrase - why would they lose part of their money - much money? I
can't see what would be their profit on releasing UE under open source
license. Moreover, what would be profit of others except the right of copying
their code?

~~~
cyphar
> I can't see what would be their profit on releasing UE under open source
> license.

They have already forgone a lot of potential revenue by allowing anyone to get
the source code for the engine (under a proprietary license) without paying
anything. The only thing left is to design a non-royalty revenue model that
can work with a free software license. This has already been solved.

> Moreover, what would be profit of others except the right of copying their
> code?

Being able to release free software games using UE. Creating a community
around UE that allows for innovation by that community. Porting to new
platforms by that community. A show of good will to the free software
community. There are many good reasons, but they all come about from giving
people software freedom.

~~~
EvgeniyZh
> They have already forgone a lot of potential revenue by allowing anyone to
> get the source code for the engine (under a proprietary license) without
> paying anything.

They're making to pay only those who has profits from using their engine.
Those who has no profits (i.e. less than $3000) wouldn't buy it anyway.

> Being able to release free software games using UE.

You can do that now.

> Creating a community around UE that allows for innovation by that community.

There is a community.

> Porting to new platforms by that community.

You can do that now.

> There are many good reasons, but they all come about from giving people
> software freedom.

I am for free software, but I don't like ideology in name of ideology.

------
Qantourisc
I'm happy to see usable non x86 hardware ! But we still have to solve
emulation. I wonder if there is a way to decompile and recompile binaries. In
theory it SHOULD be possible to convert what the CPU is asked to do, back to
what the program does, and then convert it to another CPU.

An implementation like this would have a huge impact on new platform giving
them a fighting change, allow competition without vendor lock-in.

~~~
versteegen
Machine code translation is exactly how Intel Atom Android phones support apps
containing native ARM code. Intel has a translator from ARM to x86 or x86_64
called Houdini. (I never managed to find any detailed information about it,
it's propriety). Even if you're developing an app for Android using the NDK
you may not realise that your phone doesn't have an ARM processor. Few people
bother to ship x86 binaries, and the fact that works so well is why they still
don't even as x86 devices become more common (they're mostly tablets).
Compatibility is around 80% of apps [0], and the performance hit is somewhat
substantial (e.g. 2x) but doesn't matter for most apps.

[0]
[https://regmedia.co.uk/2014/04/30/watt_compatibility_large.j...](https://regmedia.co.uk/2014/04/30/watt_compatibility_large.jpg)
[1] [https://commonsware.com/blog/2013/11/21/libhoudini-what-
it-m...](https://commonsware.com/blog/2013/11/21/libhoudini-what-it-means-for-
developers.html)

