Q:

How fair is a direct comparison of clock frequencies of an ARM and and x86 processor? 

I was wondering, if I got an ARM processor (1GHz) and a x86 processor² (1GHz) and no other information about them, is it possible to give a general statement about which one of them would probably perform better in executing some arbitrary (complex) application.  
I know the ARM (RISC) architecture was specifically developed to aid certain applications whereas the x86 architecture is just a compilation of legacy compatibility and workarounds (no bashing intended).  Naturally, it would be important to know a little bit more about the application, i.e. which specific tasks (and thus instructions) might be executed most.  Let's also put aside that there are different versions of those architectures. 
Thus my question: Having those two unspecified processors with 1GHz clock frequency, is it possible to give an educated guess which one would perform better (i.e. will execute a general but complex application faster). 
On a second note: If not possible (which is what I assume) what general parameters would be at least necessary to compare – except for comparing the assembly code of the application with the respective instruction sets of the architectures? 

² to keep it simple, let's suppose they've got both a 32bit architecture and no specific AMD or Intel features. 

A:

Following are comparisons from my 32 bit GCC benchmarks - Read more on my site::
http://www.roylongbottom.org.uk/ 
They represent percentage operations per CPU clock Hz for Android systems (Atom native Intel code), Raspberry Pi 2 A7 and Intel/AMD based PCs using Linux Ubuntu.  
First is from Whetstone benchmark with tiny loops, where Intel and ARM can be quite similar. 
Next is  Linpack benchmark with L2 cache speed dependency, where later technology shows improvements.  
Finally, my maximum MFLOPS tests, with SSE instructions compiled for Intel and NEON for ARM, with Intel leaping ahead.  Core i7 with AVX directive demonstrated up to 1147 MFLOPS per MHz.  
Note results can depend on compiler release version. 
                       Whetstone                 Linpack      Max
                        Float Functions  Integer    Float    Float

    Cortex-A9              22      1.7      124       17       95
    Cortex-A15             18      1.7      102       47      241
    Qualcomm 800           27      1.5      146       33
    Atom Z3745             30      1.7      182       22

    Cortex-A7              27      0.9      126       13       86

    Atom N455              19      0.7       63       12      110
    Athlon 64              28      1.6      113       42
    Phenom II              28      1.6      136       49      500
    Core 2 Duo             31      1.6      238       41      600
    Core i7 4820K          31      1.8      224       65      630

A:

Not really.   An x86 clocked that low might be a low-power design like Atom (esp.  pre-Silvermont), or even-more-limited x86 design.   Modern desktop/laptop x86 CPUs can do a LOT per clock (about 4 instructions per clock, barring branch mispredicts, data dependencies, or execution port contention).   Google if you want IPC (insns per cycle) numbers for desktop CPUs on real code. 
One CPU might be faster for some things, but slower for others, for tasks that stress different items on this list (that I just made up):

Vector integer and/or FP math throughput
unpredictable branches (data compression)
workload size (cache)
bandwidth to main memory
bandwidth to cache
large-code-footprint (instruction cache/fetch/branch-prediction buffer size)
AES / CRC32C / SHA1 (supported by HW instructions in some CPUs). 

How to actually compare
Look at the gcc benchmark results from SPECint2000 or SPECint2006.   The other benchmarks that make up the whole SPECint suites are generally regarded as not as useful these days.   (source - Realworldtech forum discussion.   And yes, the "Linus" he's agreeing with is Linus Torvalds of Linux fame.) 

You can't game gcc, it has a fairly large cache footprint relative to
  the others, stresses the branch predictor, etc.  Since SPEC doesn't
  include browser or GUI benchmarks, gcc is probably the closest you can
  come to actually measuring smartphone performance.